WebRTC nie „otwiera portu” — negocjuje możliwą ścieżkę#

Przeglądarka zwykle działa za NAT, często bez wiedzy o publicznym adresie i polityce sieci. Druga strona może znajdować się w innej sieci, za kolejnym NAT albo w infrastrukturze operatora. ICE organizuje proces znalezienia pary adresów, przez którą da się przesłać media.

W uproszczeniu endpoint zbiera kandydatów, wymienia ich przez signaling, testuje połączenia i wybiera działającą parę. Signaling może używać SIP over WebSocket, własnego API lub innego kanału. ICE nie definiuje sposobu przesyłania oferty między stronami.

Trzy główne typy kandydatów#

Kandydat ICE zawiera adres, port, transport, priorytet i typ. Najczęściej spotkasz:

TypŹródłoCo reprezentuje
hostlokalny interfejsadres widoczny bezpośrednio na urządzeniu
srflxodpowiedź STUNpubliczne mapowanie utworzone przez NAT
relayalokacja TURNadres serwera, który przekazuje media

Przykładowa linia:

text
a=candidate:1 1 UDP 2122260223 192.168.1.20 54436 typ host

Kandydat host może być użyteczny w tej samej sieci LAN lub przez VPN. Kandydat srflx pozwala spróbować komunikacji przez mapowanie NAT. Kandydat relay jest najbardziej uniwersalny, bo obie strony komunikują się z osiągalnym serwerem TURN.

STUN odkrywa mapowanie, ale nie gwarantuje ścieżki#

Klient wysyła Binding Request do serwera STUN i otrzymuje informację o adresie oraz porcie widocznym z zewnątrz. To tworzy kandydat server reflexive. Jeżeli NAT i firewall pozwalają drugiej stronie wysłać pakiety na to mapowanie, media mogą płynąć bez relay.

Problem polega na tym, że mapowanie może być zależne od celu. Adres poznany w komunikacji ze STUN nie musi zachowywać się identycznie wobec innego peer'a. Sieć może też blokować przychodzący UDP, mieć krótki timeout albo stosować CGNAT.

TURN tworzy kontrolowany punkt relay#

TURN przydziela klientowi adres na serwerze. Druga strona wysyła media do tego adresu, a TURN przekazuje je do klienta. Rozwiązanie zwiększa niezawodność w restrykcyjnych sieciach, ale zużywa pasmo serwera i dodaje dodatkowy hop.

TURN powinien zapewniać co najmniej UDP, a jako ścieżkę awaryjną często również TCP i TLS. Typowe porty nasłuchujące to 3478 dla STUN/TURN i 5349 dla TURN over TLS, lecz sama kontrola połączenia nie wystarcza. Trzeba otworzyć zakres portów relay, z którego serwer przydziela alokacje.

Przykładowa topologia:

text
Browser A ----\
               TURN relay ---- Media gateway / Browser B
Browser B ----/

Dane uwierzytelniające TURN nie powinny być stałym sekretem osadzonym bezterminowo w publicznym JavaScript. W systemach produkcyjnych warto generować krótkotrwałe credentials albo pobierać je po uwierzytelnieniu użytkownika.

ICE checks i wybór candidate pair#

Po wymianie kandydatów endpointy tworzą listę par. Connectivity checks używają STUN do potwierdzenia, czy pakiety przechodzą w obie strony. Jedna strona jest controlling, druga controlled. Wybrana para staje się ścieżką mediów.

Priorytet zwykle preferuje połączenie bezpośrednie, a relay jest fallbackiem. Nie należy jednak diagnozować wyłącznie na podstawie kolejności kandydatów w SDP. Sprawdź faktyczną parę:

  • Chrome: chrome://webrtc-internals,
  • Firefox: about:webrtc,
  • API RTCPeerConnection.getStats(),
  • logi biblioteki lub gatewaya WebRTC.

Szukaj selectedCandidatePair, typu lokalnego i zdalnego kandydata, liczby wysłanych/odebranych bajtów, RTT oraz zmian stanu ICE.

Trickle ICE przyspiesza, ale wymaga poprawnego signalingu#

Bez trickle ICE aplikacja czeka na zakończenie zbierania kandydatów przed wysłaniem pełnej oferty. Trickle ICE pozwala przesyłać kandydatów w miarę ich odkrywania. Skraca czas zestawienia, ale kanał signalingu musi poprawnie obsłużyć dodatkowe komunikaty i zakończenie gathering.

Typowe błędy:

  • kandydaty przychodzą przed utworzeniem remote description,
  • aplikacja gubi kandydaty podczas reconnectu WebSocket,
  • end-of-candidates nie jest obsłużony,
  • gateway nie wspiera trickle, choć klient go używa,
  • kandydat mDNS jest traktowany jak zwykły adres DNS.

Jeżeli połączenie działa tylko po drugim podejściu, warto sprawdzić kolejność setLocalDescription, setRemoteDescription i addIceCandidate.

DTLS-SRTP: osiągalność to jeszcze nie media#

Po wybraniu ścieżki WebRTC zestawia DTLS, uzgadnia klucze i chroni RTP przez SRTP. Fingerprint z SDP wiąże certyfikat DTLS z negocjacją. Dlatego stan ICE connected nie gwarantuje, że audio popłynie. DTLS może nie zakończyć handshake, fingerprint może się nie zgadzać albo gateway może używać niewłaściwej roli.

Kolejność diagnostyczna:

  1. Czy signaling wymienił kompletne SDP?
  2. Czy ICE wybrało parę kandydatów?
  3. Czy pakiety STUN docierają w obu kierunkach?
  4. Czy DTLS handshake zakończył się sukcesem?
  5. Czy pojawiły się pakiety SRTP i rosną liczniki bajtów?
  6. Czy track jest aktywny i nie jest wyciszony przez aplikację?

Ta kolejność oddziela sieć od kryptografii i logiki aplikacyjnej.

Porty i firewall w praktyce#

Dla serwera TURN sprawdź trzy grupy ruchu:

  • porty klient → TURN dla UDP/TCP/TLS,
  • zakres relay używany przez alokacje,
  • komunikację TURN → peer lub media gateway.

W chmurze reguła hostowego firewalla może być poprawna, ale security group nadal blokuje zakres. W Dockerze publikowanie tylko 3478 nie publikuje automatycznie portów relay. Jeżeli coturn działa bez host network, mapowanie szerokiego zakresu wymaga świadomej konfiguracji i oceny wydajności.

Dla WebSocket signalingu potrzebny jest również poprawny WSS, certyfikat i reverse proxy obsługujący Upgrade. Błąd signalingu może wyglądać jak ICE failure, bo kandydaty nie docierają do drugiej strony.

Typowe wzorce awarii#

Działa w LAN, nie działa z Internetu#

Najczęściej używany jest kandydat host, a srflx lub relay nie jest dostępny. Sprawdź konfigurację iceServers, DNS, credentials i porty TURN.

Działa przez Wi-Fi, nie działa w sieci firmowej#

Sieć może blokować UDP. Potrzebny jest TURN po TCP/TLS, często na porcie dozwolonym przez politykę organizacji. Trzeba też ocenić proxy, inspekcję TLS i timeouty.

ICE connected, brak audio#

Przejdź do DTLS-SRTP, tracków, kodeków i kierunku sendrecv. Sprawdź, czy selected pair ma rosnące bytesSent i bytesReceived.

Połączenie zrywa się po zmianie sieci#

Zmiana z Wi-Fi na LTE może wymagać ICE restart. Aplikacja i gateway muszą obsłużyć nową generację credentials oraz kandydatów.

Minimalna checklista produkcyjna#

  • Co najmniej dwa niezależne adresy TURN lub mechanizm wysokiej dostępności.
  • UDP jako preferowana ścieżka oraz TCP/TLS jako fallback.
  • Ograniczony, jawny zakres portów relay.
  • Krótkotrwałe credentials i kontrola nadużyć.
  • Monitoring alokacji, pasma, błędów auth i czasu odpowiedzi.
  • Testy z LTE, CGNAT, sieci firmowej i restrykcyjnego Wi-Fi.
  • Rejestrowanie selected candidate pair w diagnostyce klienta.
  • Alert na brak relay candidates lub rosnący udział nieudanych ICE.

WebRTC staje się przewidywalne, gdy przestajesz traktować ICE jako czarną skrzynkę. Kandydaci opisują opcje, connectivity checks potwierdzają ścieżkę, DTLS zabezpiecza media, a statystyki pokazują, co faktycznie zostało wybrane.