STUN & TURN SERVER

Session Traversal Utilities for NAT atau disingkat STUN merupakan server yang membantu terjalinnya komunikasi atara perangkat yang berada di balik NAT (Network Address Translation) contohnya melakukan Video Call atau video conference.

STUN Server membantu client yang berada dibelakang NAT untuk saling terhubung satu sama lain.

STUN Server memungkinkan client untuk mengetahui IP Publik, jenis NAT, dan informasi port pada NAT. Informasi tersebut digunakan untuk membuat komunikasi UDP sehingga komunikasi dapat terjalin.

NAT Travelsal?

Network Adress Translation Travelsal adalah teknik untuk membuat dan memelihara komunikasi antar jaringan berbeda yang berada dibalik NAT. Contoh kasus nya adalah bagaimana menghubungkan perangkat di lokasi berbeda namun tidak memiliki IP Publik, nah disinilah digunakan teknik NAT Travelsal untuk melangkahi NAT/Firewall tersebut.

Terdapat banyak macam Teknik NAT Travelsal, ada yang langsung, peer-to-peer dan ada dengan cara relay seperti proxy.

PUBLIC STUN SERVER

STUN server hanya bertugas memberikan informasi network path guna mengidentifikasi external address yang digunanakan oleh komputer untuk melakukan port-mapping. Tidak ada transmisi data yang dilewatkan melalui STUN Server. karena tugasnya yang cukup ringan, ada beberapa STUN Server yang dapat anda gunakan gratis, salah satunya milik Google.

TURN SERVER ?

Ketika transmisi data secara langsung/peer-to-peer gagal dilakukan, transmisi data secara Relay umum nya dijadikan sebagai alternatif. Traversal Using Relay NAT (TURN) Server bekerja dengan meneruskan data / Relay ke komputer tujuan mirip seperti Proxy.

Pada WebRTC, STUN dan TURN digunakan sekaligus. STUN digunakan terlebih dahulu, bila koneksi secara peer-to-peer dengan bantuan STUN Server gagal, transmisi secara relay (TURN) akan digunakan.

STUN & TURN pada WebRTC

Diagram STUN dan TURN server kurang lebih seperti dibawah ini, diagram ini dibuat berdasarkan WebRTC yang menggunakan standar ICE (Interactive Connectivity Establishment RFC5245 ) model offer/answer

Pada contoh diagram diatas, 2 buah client berada dibalik Firewall atau NAT, kita anggap itu berada dibalik ISP tanpa ip public. Keduanya akan saling berukar media untuk melakukan video call.

Untuk memulai sebuah sesi video call, Client A terlebih dahulu meng-generate Session Description Protocol (SDP) offer. SDP tersebut berisi informasi mengenai sesi yang diinginkan oleh Client A, codec yang akan digunakan, audio atau video, dll. SDP juga berisi beberapa informasi ICE Candidates, yang menjelaskan IP & Port yang akan digunakan untuk terhubung. ICE Candidates tersebut didapat dari STUN Server.

Setelah SDP Offer lengkap, informasi tersebut dikirimkan ke Client B melalui Signaling Server. Signaling Server disini bisa berupa server chat/Websocket atau apapun itu yang bisa meneruskan data SDP dari Client A ke Client B.

Ketika SDP diterima oleh Client B, SDP tersebut akan dijawab, istilah nya SDP Answer. Client B akan melakukan proses yang mirip seperti dilakukan pada Client A sebelumnya. Kemudian SDP Answer tersebut dikirimkan ke Client A melalui signaling server.

Ketika kedua client tersebut saling bertukar SDP, mereka akan melakukan Connectivity Check. ICE pada masing – masing browser akan mengambil daftar IP/Port dari SDP yang diterima dan kemudian akan melakukan STUN Request.

Setelah Connectivity Check selesai pada semua IP/Port, browser akan memilih salah satu IP/Port yang valid, kemudian Media akan mengalir antara client tersebut secara langsung.

Jika browser tidak menemukan IP/Port yang valid mereka akan membuat STUN Request ke TURN Server untuk mendapatkan relay addres. Informasi tersebut akan dimasukan kedalam candidate list dan dikirim melalui signaling server.

Tutorial cara membuat TURN & TURN Server sendiri akan dibuat pada artikel selanjut nya…