STUN i TURN poslužitelji: što je videopozivu potrebno da se spoji

Videopoziv u pregledniku na prvi pogled trebao bi biti jednostavan. WebRTC šalje zvuk i video izravno s jednog uređaja na drugi, bez poslužitelja u sredini. Zatim ga isprobate izvan vlastite mreže i neki pozivi zazvone, netko se javi, ali ostanu bez zvuka i s crnim zaslonom. Kod je najčešće u redu. Nedostaje STUN poslužitelj, TURN poslužitelj ili oba.

Ovaj članak objašnjava što svaki od njih radi, zašto ih poziv treba, što je potrebno za vlastiti TURN poslužitelj i što učiniti s pozivima koje ne može spojiti ni relej.

Zašto se dva uređaja ne mogu jednostavno spojiti

Gotovo nijedan uređaj na internetu nema vlastitu javnu adresu. Prijenosno računalo kod kuće nalazi se iza routera, mobitel iza svog operatera, a uredsko računalo iza vatrozida. Svaki od njih zna samo svoju privatnu adresu, poput 192.168.1.23, koja drugoj strani poziva ne znači ništa.

Prije nego što poziv može početi, svaki uređaj mora saznati kako se može doći do drugoga, a njih dvoje moraju isprobavati te načine dok jedan ne proradi. WebRTC to radi pomoću ICE-a, koji za svaki uređaj prikuplja adrese kandidate i isprobava ih u parovima. Neki od tih kandidata dolaze od STUN-a i TURN-a.

Što radi STUN poslužitelj

STUN poslužitelj odgovara na jedno pitanje: „koja je moja adresa, onako kako je ti vidiš?“ Uređaj mu pošalje mali zahtjev, a poslužitelj odgovori javnom adresom i portom s kojih je zahtjev stigao. Uređaj tu adresu doda svojim kandidatima, druga je strana isproba i na većini kućnih mreža poziv se spoji izravno.

STUN je jeftin. Vidi nekoliko malih paketa na početku poziva i ništa nakon toga, pa jedan STUN poslužitelj može služiti velik broj poziva, a postoje i javni koje svatko može koristiti. Kad izravni put postoji, STUN je sve što poziv treba.

Što radi TURN poslužitelj

Ponekad izravni put ne postoji. Strogi vatrozid ne pušta ništa unutra, mobilni operater mobitelu daje drugi javni port za svako novo odredište ili mreža tvrtke dopušta samo web promet. Adresa koju je javio STUN ne radi za drugu stranu i poziv ne uspijeva.

TURN poslužitelj je relej za takve pozive. Oba se uređaja spajaju prema njemu, a on između njih prosljeđuje njihov zvuk i video. Budući da uređaji uspostavljaju samo odlazne veze, koje dopušta gotovo svaka mreža, poziv prolazi ondje gdje izravni ne može.

Prosljeđivanje ima trošak koji STUN nema: svaka sekunda zvuka i videa prolazi kroz relej, u oba smjera, dok god poziv traje. Videopoziv jedan na jedan kroz njega može prenositi nekoliko megabita u sekundi. Zato postoje javni STUN poslužitelji, ali ne i pouzdani slobodno dostupni TURN poslužitelji: relej otvoren svima ubrzo prenosi promet koji njegov vlasnik nikad nije namjeravao prenositi, pa ga se ugasi ili zaštiti pristupnim podacima.

Pokretanje vlastitog TURN poslužitelja

Postoje TURN poslužitelji otvorenog koda koji dobro rade i mnogi timovi počinju s njima. Što je za to potrebno:

• Poslužitelj s javnom adresom i velikom propusnošću, blizu vaših korisnika. Relej na drugom kontinentu dodaje kašnjenje koje ljudi čuju.
• Pravi portovi. Uobičajeni je port 3478 preko UDP-a i TCP-a. Za mreže koje dopuštaju samo web promet relej mora odgovarati i na portu 443 s TLS-om, što znači certifikat za njegovo ime, obnovljen na vrijeme.
• Pristupni podaci koji istječu. TURN poslužitelj nikad ne bi smio primati fiksno korisničko ime i lozinku koji stoje na vašoj stranici, gdje ih svatko može kopirati. Uobičajeni je način tajni ključ koji dijele vaša aplikacija i relej: vaš poslužitelj za svaki poziv izrađuje korisničko ime i lozinku koji nakon nekog vremena prestaju vrijediti.
• Više od jednog, kako rastete. Jedan relej jedna je točka na kojoj mogu pasti svi pozivi. Korisnici u drugim regijama žele relej blizu sebe, a svaki treba nadzor, ažuriranja i prostor za rast.
• Testiranje iz stvarnih mreža. Relej koji radi iz vašeg ureda može zakazati s mobitela na mreži operatera ili s prijenosnog računala na hotelskom Wi-Fiju. Testirajte iz mreža na kojima su vaši korisnici.

Ništa od toga nije teško, ali to je usluga koju treba održavati u radu dok god vaša aplikacija ima pozive.

Kad ni TURN ne može spojiti poziv

Relej rješava većinu neuspjelih poziva, ali ne svaki. Neke mreže blokiraju UDP kojem relej daje prednost, a neke ometaju duge veze čak i na portu 443. Za njih poziv može otići korak dalje, u sobu na medijskom poslužitelju, onakvom na kakvom rade grupni pozivi. Dvije osobe tada šalju medijskom poslužitelju i od njega primaju jedna drugu, a taj put izdržava na mrežama na kojima bilo kakav peer-to-peer prijenos medija ima poteškoća.

Poziv koji onamo može prijeći tek nakon što ne uspije prvo bi se prekinuo. Bolji je način održati poziv dok mijenja put, tako da ljudi u njemu primijete trenutak zamrzavanja, a ne prekinut poziv.

Kako WordPlus Cloud spaja pozive

WordPlus Cloud pokreće sva tri puta, pa se poziv između dviju osoba uvijek spoji, na bilo kojoj mreži:

1. Izravno, između dvaju uređaja, na većini mreža. Najbrži put.
2. Preko naših releja, kad vatrozid blokira izravni put. Odgovaraju na portovima weba, 443 i 80, kao i na 3478, pa poziv prolazi svugdje gdje prolaze web-stranice. Svaka osoba u svakom pozivu dobiva vlastite pristupne podatke za releje koji istječu nakon nekoliko sati, pa nitko ne može koristiti releje izvan vaših poziva.
3. Preko naših medijskih poslužitelja, kad ni releji ne mogu prenijeti poziv. Poziv prelazi tamo i nastavlja se, bez prekidanja.

Pozivi su šifrirani s kraja na kraj na svakom putu, ključem koji daje samo vaš poslužitelj, pa releji i medijski poslužitelji prenose ono što ne mogu pročitati. Pozivi između dviju osoba uključeni su u svaki plan, prolazili kroz relej ili ne. Vaš poslužitelj i dalje odlučuje tko smije zvati koga, a oblak to provodi.

Sve to radi jednako u Better Messagesu na WordPressu i u vašim vlastitim aplikacijama, na Next.js, Laravelu, Djangu i drugim stackovima, s našim SDK-ovima. Stranica Videopozivi i grupni pozivi za vašu aplikaciju pokazuje što vam SDK-ovi daju, a stranica Kako pozivi rade u našoj dokumentaciji pokazuje kod.