Ścieżki mediów dla połączeń wideo

Ścieżka sieciowa	Port serwera STUN/Relay
1: Bezpośredni UDP peer-to-peer, z przechodzeniem NAT wspieranym przez serwer STUN Każdy punkt końcowy wykryje swój zewnętrzny adres internetowy przy użyciu dostarczonego serwera STUN. Ten adres jest dostarczany do drugiego punktu końcowego i używany do konfigurowania połączenia poprzez translację adresów sieciowych. Media przepływają przez losowo wybrane porty w szerokim zakresie portów UDP 49152–65535.	3478 (UDP)
2: Przez serwer przekazujący połączenia wideo, przy użyciu wyjścia wychodzącego kierowanego przez UDP Jeśli nie można nawiązać połączenia przy użyciu powyższego bezpośredniego typu peer to peer, skonfigurowany port 3478 UDP serwera TURN będzie próbował nawiązać połączenie ze zdalnym punktem końcowym. Ten adres przekaźnika jest dostarczany do drugiego punktu końcowego i używany do konfigurowania połączenia za pośrednictwem przekaźnika z powrotem przez połączenie lokalnego punktu końcowego z serwerem TURN. Media przepływają do portu UDP 3478 na serwerze TURN.	3478 (UDP)
3: Za pośrednictwem serwera przekazującego połączenia wideo, przy użyciu połączenia wychodzącego kierowanego przez TCP Jeśli nie można nawiązać połączenia z serwerem TURN za pomocą UDP, połączenie z serwerem TURN jest nawiązywane przez TCP 443, a nie UDP 3478. Media przepływają na zewnątrz do portu TCP 443 na serwerze TURN.	3478 (TCP)
4: Za pośrednictwem serwera przekazującego połączenia wideo przy użyciu tunelowania TCP przez lokalny serwer proxy sieci web Jeśli nie można nawiązać połączenia routowanego przez NAT z serwerem TURN, zostanie podjęta próba połączenia tunelowego z portem TCP 443 za pośrednictwem skonfigurowanego w przeglądarce internetowej serwera proxy. Media przepływają na zewnątrz przez web proxy do portu TCP 443 na serwerze TURN.	443 (TCP)
5a, 5b: Za pośrednictwem serwera przekazującego połączenia wideo przy użyciu bezpiecznego protokołu TCP Jak w przypadku 3 lub 4 powyżej, ale przy użyciu połączenia TLS TCP z serwerem TURN.	443 (TCP/TLS)

Ścieżka sieciowa

Port serwera STUN/Relay

1: Bezpośredni UDP peer-to-peer, z przechodzeniem NAT wspieranym przez serwer STUN

Każdy punkt końcowy wykryje swój zewnętrzny adres internetowy przy użyciu dostarczonego serwera STUN. Ten adres jest dostarczany do drugiego punktu końcowego i używany do konfigurowania połączenia poprzez translację adresów sieciowych.

Media przepływają przez losowo wybrane porty w szerokim zakresie portów UDP 49152–65535.

3478 (UDP)

2: Przez serwer przekazujący połączenia wideo, przy użyciu wyjścia wychodzącego kierowanego przez UDP

Jeśli nie można nawiązać połączenia przy użyciu powyższego bezpośredniego typu peer to peer, skonfigurowany port 3478 UDP serwera TURN będzie próbował nawiązać połączenie ze zdalnym punktem końcowym. Ten adres przekaźnika jest dostarczany do drugiego punktu końcowego i używany do konfigurowania połączenia za pośrednictwem przekaźnika z powrotem przez połączenie lokalnego punktu końcowego z serwerem TURN.

Media przepływają do portu UDP 3478 na serwerze TURN.

3478 (UDP)

3: Za pośrednictwem serwera przekazującego połączenia wideo, przy użyciu połączenia wychodzącego kierowanego przez TCP

Jeśli nie można nawiązać połączenia z serwerem TURN za pomocą UDP, połączenie z serwerem TURN jest nawiązywane przez TCP 443, a nie UDP 3478.

Media przepływają na zewnątrz do portu TCP 443 na serwerze TURN.

3478 (TCP)

4: Za pośrednictwem serwera przekazującego połączenia wideo przy użyciu tunelowania TCP przez lokalny serwer proxy sieci web

Jeśli nie można nawiązać połączenia routowanego przez NAT z serwerem TURN, zostanie podjęta próba połączenia tunelowego z portem TCP 443 za pośrednictwem skonfigurowanego w przeglądarce internetowej serwera proxy.

Media przepływają na zewnątrz przez web proxy do portu TCP 443 na serwerze TURN.

443 (TCP)

5a, 5b: Za pośrednictwem serwera przekazującego połączenia wideo przy użyciu bezpiecznego protokołu TCP

Jak w przypadku 3 lub 4 powyżej, ale przy użyciu połączenia TLS TCP z serwerem TURN.

443 (TCP/TLS)

Osiągnięcie najlepszej jakości połączenia

1. W przypadku większości ścieżek sieciowych negocjacja prawdopodobnie zakończy się prawidłowym połączeniem multimedialnym.

Bezpośrednie połączenie peer-to-peer przez UDP zapewnia najlepsze połączenie , ale często będzie niedostępne w sieciach instytucjonalnych ze względu na ograniczenia bezpieczeństwa ich zasad sieciowych.

Bezpieczne tunelowane połączenie TCP jest najmniej pożądaną opcją przesyłania multimediów, ale najprawdopodobniej będzie obsługiwane bez zmian w zabezpieczeniach sieci.

Zalecana opcja: W przypadku wielu sieci zezwolenie na wyjście NAT do portu UDP 3478 na serwerze przekazującym (ścieżka sieci 2, powyżej) zapewni niskie opóźnienia przy niewielkim nakładzie pracy. Powinno to wymagać jedynie niewielkiej zmiany konfiguracji sieci o niskim ryzyku.

2. Aby upewnić się, że ruch z połączeń wideo ma priorytet w komunikacji w czasie rzeczywistym, zapoznaj się z poniższymi opcjami:

Jeśli twój router jest w stanie priorytetyzować ruch z wartością pola DSCP 34 (aka Assured Forwarding 41 lub AF41), możesz to skonfigurować. Cały ruch WebRTC w czasie rzeczywistym jest oznaczony w ten sposób, co poprawi jakość połączeń wideo i innych rozwiązań wideokonferencyjnych.

Jeśli twój router nie obsługuje powyższej funkcji, możesz ustawić QoS, aby priorytetyzować pakiety UDP w zakresie portów 5000-40000, co pomoże priorytetyzować pakiety wideo i zmniejszyć opóźnienia. WebRTC wykorzystuje protokół RTP do dostarczania strumieni multimedialnych, a RTP zwykle używa protokołu UDP 5000-40000. Może to spowodować nadanie priorytetu niektórym pakietom, które tego nie potrzebują, ale większość będzie to pakiety RTP. Skonfigurowanie QoS w ten sposób zapewni, że strumienie wideo będą miały jak najmniej przerw i fluktuacji.