{"id":11859,"date":"2025-04-12T03:04:24","date_gmt":"2025-04-11T18:04:24","guid":{"rendered":"https:\/\/chat-messenger.com\/?p=11859"},"modified":"2025-04-12T03:23:33","modified_gmt":"2025-04-11T18:23:33","slug":"webrtc-stun-turn-turns-sfu","status":"publish","type":"post","link":"https:\/\/chat-messenger.com\/id\/blog\/webrtc-stun-turn-turns-sfu","title":{"rendered":"Penjelasan dan praktik menyeluruh tentang STUN\/TURN\/TURNS\/SFU di WebRTC"},"content":{"rendered":"<h2>Apa itu WebRTC?<\/h2>\n\n\n\n<p>WebRTC (Web Real-Time Communication) adalah teknologi terbuka yang memungkinkan komunikasi audio, video, dan data secara real-time antar peramban. WebRTC sedang distandarisasi oleh berbagai perusahaan, termasuk Google, sebagai mekanisme yang memungkinkan komunikasi P2P hanya menggunakan API JavaScript, tanpa memerlukan plug-in atau perangkat lunak tambahan.<\/p>\n\n\n\n<p>WebRTC terdiri dari tiga komponen utama:<\/p>\n\n\n\n<ul><li><strong>dapatkanMediaPengguna<\/strong>: API untuk memperoleh audio dan video dari perangkat seperti kamera dan mikrofon.<\/li><li><strong>Koneksi RTCPeer<\/strong>:API inti untuk membangun komunikasi antara rekan dan bertukar media dan data.<\/li><li><strong>Saluran Data RTC<\/strong>: Saluran data yang dapat digunakan untuk mengirim berkas, mengobrol, dll.<\/li><\/ul>\n\n\n\n<p>API ini memungkinkan pengembangan berbagai aplikasi waktu nyata seperti panggilan video, konferensi audio, berbagi berkas, dll. Namun, dalam komunikasi aktual, terdapat masalah dengan traversal NAT dan firewall, sehingga penting untuk memahami dan menerapkan teknologi traversal NAT seperti STUN\/TURN\/TURNS.<\/p>\n\n\n\n<h2>Perbedaan dan peran STUN, TURN, dan TURNS<\/h2>\n\n\n\n<p>Mekanisme traversal NAT sangat penting untuk mencapai koneksi peer-to-peer yang stabil dengan WebRTC. Artikel ini memberikan penjelasan mendetail tentang tiga teknologi utama, STUN, TURN, dan TURNS, termasuk perbedaan teknis, skenario penggunaan, serta kelebihan dan kekurangannya.<\/p>\n\n\n\n<p>STUN adalah protokol yang terutama digunakan untuk menemukan alamat eksternal sendiri dalam lingkungan NAT, sementara TURN adalah protokol yang berfungsi sebagai server relai ketika koneksi langsung tidak memungkinkan. Di sisi lain, TURNS mengenkripsi komunikasi TURN dengan TLS dan menggunakan port 443, sama seperti HTTPS, sehingga memungkinkan komunikasi di balik firewall yang ketat seperti jaringan perusahaan.<\/p>\n\n\n\n<p>Dengan memahami karakteristik masing-masing dan menggunakannya secara tepat, Anda dapat meningkatkan tingkat keberhasilan dan kualitas komunikasi WebRTC.<\/p>\n\n\n\n<h3>Peran dan Karakteristik STUN (UDP)<\/h3>\n\n\n\n<p>STUN (Session Traversal Utilities for NAT) adalah protokol yang memungkinkan klien untuk<strong>Alamat IP dan port eksternal<\/strong>Misalnya, jika PC Anda berada di belakang NAT, ia tidak mengetahui alamat IP globalnya sendiri, tetapi ia dapat memperoleh &quot;IP:port seperti yang terlihat dari dunia luar&quot; dengan menanyakan server STUN.<\/p>\n\n\n\n<p>Server STUN bertindak seperti cermin, mengembalikan informasi sumber permintaan yang diterima persis seperti aslinya. Hasilnya, klien dapat mengetahui alamat IP globalnya sendiri dan nomor port yang ditetapkan oleh NAT (Server Reflexive Candidate).<\/p>\n\n\n\n<p>Komunikasi STUN biasanya dilakukan melalui UDP, dengan port default 3478 (UDP\/3478). Karena hanya memerlukan komunikasi single-shot yang ringan melalui UDP, komunikasi ini memiliki overhead yang rendah, latensi yang rendah, dan hampir tidak membebani server. Oleh karena itu, dalam lingkungan yang mengizinkan komunikasi UDP, traversal NAT menggunakan STUN dicoba terlebih dahulu.<\/p>\n\n\n\n<h4><strong>Skenario penggunaan STUN<\/strong><\/h4>\n\n\n\n<p>Ini efektif di lingkungan yang mengharuskan traversal NAT tetapi komunikasi UDP itu sendiri tidak terblokir, seperti jaringan rumah atau jaringan seluler. Jika STUN dapat memperoleh IP dan port eksternal masing-masing, klien dapat membangun komunikasi langsung (peer-to-peer). Karena jalur komunikasinya langsung, latensi rendah dan kualitas tetap terjaga pada tingkat tinggi. Selain itu, karena server hanya memfasilitasi pertukaran informasi IP, biayanya tetap sangat rendah. Misalnya, dalam gim daring atau panggilan video, jika kedua perangkat berada di belakang NAT yang relatif terbuka, STUN cukup untuk mengaktifkan koneksi peer-to-peer.<\/p>\n\n\n\n<h4>Keterbatasan dan Kerugian STUN<\/h4>\n\n\n\n<p>STUN hanyalah cara untuk &quot;menemukan alamat eksternal Anda sendiri&quot;, dan tergantung pada jenis NAT dan batasan firewall, koneksi mungkin tidak dapat dilakukan hanya dengan menggunakan cara ini. Khususnya, dalam lingkungan NAT simetris atau firewall yang ketat, paket dari pihak lain mungkin tidak mencapai alamat yang diperoleh oleh STUN, sehingga komunikasi menjadi mustahil.<\/p>\n\n\n\n<p>Selain itu, komunikasi UDP sendiri mungkin terblokir di jaringan perusahaan, sehingga permintaan STUN sendiri mungkin tidak diterima. Singkatnya, STUN adalah mekanisme untuk menentukan apakah komunikasi langsung memungkinkan, dan mekanisme ini tidak akan berfungsi di lingkungan di mana komunikasi langsung secara fisik mustahil. Karena alasan ini, STUN digunakan dalam ICE (dijelaskan di bawah) untuk mendapatkan kandidat tahap pertama, dan jika STUN tidak mencukupi, mekanisme ini dirancang untuk kembali ke TURN, yang dijelaskan di bawah.<\/p>\n\n\n\n<h3>Peran dan karakteristik TURN (UDP)<\/h3>\n\n\n\n<p>TURN (Traversal Menggunakan Relay di Sekitar NAT) adalah protokol yang bertindak sebagai relai perantara ketika komunikasi langsung tidak memungkinkan menggunakan STUN. Server TURN bertindak sebagai titik relai yang dapat diakses secara global, bertindak sebagai perantara antara mitra komunikasi dan pihak lain untuk meneruskan paket. Klien terhubung ke server TURN dan mendapatkan alamat IP dan port relai, yang dikenal sebagai kandidat relai. Setelah itu, pertukaran media dan data dengan pihak lain terjadi melalui server TURN tersebut.<\/p>\n\n\n\n<p>TURN juga biasanya berkomunikasi melalui UDP, sehingga selama UDP digunakan, TURN dapat meneruskan paket media dengan cara yang mirip dengan komunikasi langsung. Secara default, protokol TURN diterima pada port 3478 (UDP), sama seperti STUN. Meskipun kebijakan firewall Anda membatasi nomor port UDP, Anda juga dapat menjalankan TURN pada port yang diizinkan seperti UDP\/443. Selama UDP tersedia, penerusan dengan kinerja waktu nyata yang lebih tinggi daripada TCP dimungkinkan.<\/p>\n\n\n\n<h4>Skenario penggunaan TURN<\/h4>\n\n\n\n<p>TURN penting ketika koneksi langsung tidak dapat dibuat. Misalnya,<span class=\"swl-marker mark_blue\">Hal ini terjadi ketika satu atau kedua belah pihak berada di balik firewall perusahaan yang ketat, atau ketika kedua belah pihak memiliki NAT simetris, yang dapat menyebabkan kegagalan pengetikan lubang UDP.<\/span>Dalam lingkungan seperti itu, komunikasi tidak mungkin dilakukan tanpa meneruskan melalui server TURN, jadi TURN bertindak sebagai semacam pilihan terakhir.<\/p>\n\n\n\n<p>WebRTC bertujuan agar semua rekan dapat berkomunikasi secara langsung, tetapi meskipun hal ini tidak memungkinkan, komunikasi dapat dilanjutkan dengan menggunakan TURN. Dalam pengoperasiannya, strategi umumnya adalah mencoba koneksi langsung menggunakan STUN terlebih dahulu, dan baru beralih ke relai TURN jika gagal. Misalnya, dalam konferensi video melalui jaringan internal, jika dua rekan tidak dapat berkomunikasi secara langsung, sistem akan secara otomatis beralih ke komunikasi melalui server TURN, yang memungkinkan percakapan berlanjut tanpa sepengetahuan pengguna.<\/p>\n\n\n\n<h4><strong>Manfaat TURN<\/strong><\/h4>\n\n\n\n<p>Keunggulan terbesarnya adalah keandalan. Bahkan di lingkungan NAT atau firewall apa pun, komunikasi peer-to-peer pada akhirnya dapat tercapai selama komunikasi dapat terjalin dari klien ke server TURN. TURN juga merupakan perluasan dari protokol STUN, sehingga satu implementasi server (seperti coturn, yang dijelaskan di bawah) dapat memproses permintaan STUN dan TURN. Setelah koneksi terjalin, media selanjutnya diteruskan sebagai aliran, sehingga komunikasi menjadi lancar dari sudut pandang pengguna, dengan sedikit penundaan.<\/p>\n\n\n\n<h4><strong>Kekurangan TURN<\/strong><\/h4>\n\n\n\n<p> Kelemahan terbesarnya adalah konsumsi sumber daya dan latensi. Dengan TURN, semua data audio dan video melewati server, sehingga membutuhkan bandwidth dan daya pemrosesan yang sangat besar di sisi server. Misalnya, jika kita berasumsi bahwa panggilan video satu-ke-satu menghabiskan bandwidth 1Mbps dalam satu arah, maka dengan perhitungan sederhana, 1.000 pengguna simultan akan membutuhkan bandwidth relai sebesar 1Gbps. Hal ini membuat biaya operasional server TURN tinggi, dan layanan berskala besar memerlukan penyediaan beberapa server relai TURN agar dapat ditingkatkan skalanya.<\/p>\n\n\n\n<p>Selain itu, jalur komunikasi yang lebih panjang meningkatkan latensi, yang mengakibatkan jeda waktu video dan audio serta penurunan kualitas. Lebih lanjut, dibandingkan dengan komunikasi peer-to-peer melalui STUN, TURN tidak sepenuhnya peer-to-peer, sehingga sedikit kurang aman dalam hal kerahasiaan (meskipun server TURN biasanya hanya menyampaikan RTP\/datagram yang tidak terenkripsi dan tidak menginterpretasikan kontennya).<\/p>\n\n\n\n<p>Secara keseluruhan, TURN sebaiknya hanya digunakan jika diperlukan. Faktanya, sebagian besar komunikasi WebRTC dapat dihubungkan langsung menggunakan STUN, dan statistik Google menunjukkan bahwa sekitar 861 TP3T dari semua panggilan dibuat tanpa relai (peer-to-peer). Hanya sekitar 141 TP3T sisanya yang memerlukan TURN, tetapi penting untuk memiliki infrastruktur TURN untuk 141 TP3T tersebut.<\/p>\n\n\n\n<h3>Peran dan fitur TURNS (TLS melalui TCP\/443)<\/h3>\n\n\n\n<p>TURNS adalah singkatan dari &quot;TURN over TLS,&quot; yang berarti bahwa komunikasi relai melalui protokol TURN dienkripsi lebih lanjut dengan TLS (Transport Layer Security).<span class=\"swl-marker mark_blue\">Komunikasi TURN diamankan oleh TLS (HTTPS)<\/span>Sering disajikan pada port TCP 443.<span class=\"swl-marker mark_blue\">Port 443 adalah nomor port yang sama dengan HTTPS, sehingga dapat dengan mudah melewati firewall perusahaan dan menerobos proxy serta penyensoran.<\/span>.<\/p>\n\n\n\n<p>Misalnya, jaringan internal perusahaan mungkin hanya mengizinkan komunikasi eksternal melalui port 80 dan 443, tetapi bahkan dalam kasus ini, jika server TURN menggunakan komunikasi TLS melalui port 443, ada kemungkinan besar komunikasi tersebut dapat diteruskan. Selain itu, karena komunikasi dienkripsi TLS, komunikasi tersebut aman dan sulit disadap oleh pihak ketiga.<\/p>\n\n\n\n<p>Dalam WebRTC, pengaturannya<code>&quot;urls&quot;: &quot;turns:turnsserver:443&quot;<\/code>Dalam skema URI,<code>berubah:<\/code>Anda dapat menggunakan server TURN terenkripsi TLS ini dengan menentukan<\/p>\n\n\n\n<h4>Skenario penggunaan TURNS<\/h4>\n\n\n\n<p>TURNS berguna untuk komunikasi WebRTC di lingkungan yang sangat terbatas, seperti jaringan perusahaan, di mana semua cara lain diblokir. Bahkan di lingkungan di mana semua port UDP dan TCP umum diblokir, banyak kebijakan mengizinkan komunikasi selama diperlakukan sama dengan komunikasi HTTPS, sehingga TURN melalui port TLS 443 secara efektif merupakan pilihan terakhir.<\/p>\n\n\n\n<p>Ini juga digunakan dalam situasi di mana port tertentu ditutup pada LAN nirkabel publik, atau ketika hanya komunikasi TLS yang memungkinkan di sisi klien.<span class=\"swl-marker mark_blue\">Pertama UDP, jika tidak berhasil maka TCP, jika tidak berhasil maka TLS ke 443<\/span>Ini diposisikan sebagai tahap akhir dari kemunduran bertahap.<\/p>\n\n\n\n<h4>Manfaat TURNS<\/h4>\n\n\n\n<p>Keunggulan terbesarnya adalah ketahanannya terhadap firewall yang tinggi. Komunikasi terenkripsi TLS sulit dibedakan dari HTTPS standar, sehingga lebih mudah melewati filter yang ketat sekalipun. Khususnya, ketika memperkenalkan sistem konferensi web ke perusahaan, koneksi eksternal dari jaringan internal harus diizinkan, dan komunikasi TLS melalui TCP\/443 lebih mungkin diterima berdasarkan kebijakan keamanan. Selain itu, karena terenkripsi, kerahasiaan komunikasi ke server relai itu sendiri dapat terjamin (perlu diketahui bahwa konten itu sendiri, seperti video, seringkali sudah dienkripsi pada lapisan WebRTC).<\/p>\n\n\n\n<h4>Kerugian dari TURNS<\/h4>\n\n\n\n<p>Kelemahan terbesarnya adalah penalti kinerja. Selain latensi dan beban TURN itu sendiri, terdapat overhead tambahan dari TLS dan TCP. TCP menyediakan transportasi yang andal dan memiliki mekanisme transmisi ulang jika terjadi kehilangan paket, tetapi tidak cocok untuk media waktu nyata (real-time), dan kehilangan paket dapat menyebabkan video dan audio tidak dapat diputar dengan lancar.<\/p>\n\n\n\n<p>Selain itu, TCP rentan terhadap pemblokiran head-of-line karena urutan paket,<span class=\"swl-marker mark_blue\">Jitter (fluktuasi) juga meningkat dibandingkan dengan UDP<\/span>Lebih lanjut, pemrosesan enkripsi dan dekripsi TLS memberikan beban tambahan pada CPU. Akibatnya, dilaporkan terjadi penundaan tambahan sebesar 50 ms atau lebih, yang menyebabkan kelambatan yang dapat dirasakan oleh pengguna. Khususnya dalam konferensi video, peningkatan penundaan ini dapat memperlambat tempo percakapan dan menyebabkan perbedaan waktu yang signifikan.<\/p>\n\n\n\n<p>Dengan cara ini, TURNS dapat dianggap sebagai &quot;pilihan terakhir&quot; dalam hal kualitas, tetapi juga merupakan jalur hidup yang dapat diandalkan dalam situasi di mana tidak ada pilihan lain selain memastikan komunikasi.<\/p>\n\n\n\n<p>Dalam beberapa tahun terakhir, pendekatan baru (TURN over QUIC) yang beroperasi pada port UDP 443 dan menggunakan DTLS\/QUIC alih-alih TLS telah dipertimbangkan, tetapi masih dalam proses standarisasi dan belum digunakan secara luas.<\/p>\n\n\n\n<h2>Aliran komunikasi saat UDP STUN tidak dapat digunakan<\/h2>\n\n\n\n<p>Kami akan menjelaskan langkah demi langkah bagaimana pemrosesan WebRTC ICE berlangsung ketika STUN melalui UDP tidak tersedia. Mari kita asumsikan situasi di mana UDP diblokir sepenuhnya, seperti pada jaringan perusahaan, dan ikuti bagaimana negosiasi ICE mengalami fallback.<\/p>\n\n\n\n<ol><li><strong>Klien mengirimkan kueri IP eksternal (UDP\/3478) ke server STUN:<\/strong><br>Klien WebRTC (peramban)<code>server es<\/code>Permintaan Pengikatan (permintaan untuk memverifikasi alamat eksternal) dikirim ke server STUN yang ditentukan melalui port UDP 3478. Ini adalah langkah pertama dalam mengumpulkan kandidat ICE, dan jika berhasil, server akan mengembalikan alamat IP global dan nomor port-nya sendiri, dan menambahkannya ke daftar kandidat sebagai Kandidat Refleksif Server (kandidat srflx).<\/li><li><strong>Paket UDP diblokir oleh firewall dan tidak ada respons:<\/strong><br>Dalam kasus ini, pengaturan firewall jaringan mencegah komunikasi UDP menjangkau pihak luar. Oleh karena itu, permintaan ke server STUN tidak sampai ke server, atau responsnya tidak sampai ke klien. Akibatnya, klien<strong>Tidak ada respons STUN yang diterima<\/strong>, alamat IP eksternal tidak dapat diketahui. Agen ICE menunggu respons selama jangka waktu tertentu, tetapi terjadi batas waktu. Dari sudut pandang pengguna, koneksi masih berlangsung dan tidak ada pesan kesalahan yang ditampilkan, tetapi kenyataannya,<strong>Gagal mengumpulkan kandidat<\/strong>Hal ini sedang terjadi saat ini.<\/li><li><strong>Pemeriksaan koneksi langsung ICE gagal karena tidak ada kandidat Server Reflexive yang tersedia:<\/strong><br>Biasanya, jika STUN berhasil, klien akan memiliki kandidat Host (IP lokalnya) serta kandidat Server Reflexive (IP globalnya), dan akan memeriksa koneksi dengan menggabungkannya dengan kandidat yang sama dari rekan di ujung yang jauh. Namun, jika STUN gagal dan tidak ada kandidat IP global,<strong>Kandidat yang sangat terbatas untuk koneksi langsung dengan rekan sejawat<\/strong>Misalnya, jika kedua pihak hanya memiliki alamat IP privat, mereka tidak akan dapat saling menghubungi meskipun mencoba terhubung. Akibatnya, ICE akan menentukan bahwa &quot;komunikasi langsung tidak memungkinkan.&quot; Jika server ICE (TURN) tidak dikonfigurasi, seluruh ICE akan dianggap gagal pada tahap ini, dan koneksi WebRTC tidak akan dibuat (konsol pengembang akan menampilkan<code>ICE gagal<\/code>dan ... dan<code>Status koneksi ICE: gagal<\/code>atau kesalahan lainnya akan ditampilkan).<\/li><li><strong>Upaya untuk mendapatkan kandidat relai TURN (melalui TCP\/TLS\/443):<\/strong><br>Bahkan jika akuisisi kandidat langsung melalui STUN gagal,<code>server es<\/code>Jika server TURN ditentukan di<strong>Langkah Selanjutnya<\/strong>Dalam skenario ini, UDP tidak didukung, jadi klien mencoba untuk terhubung ke server TURN menggunakan TCP atau TLS (misalnya,<code>putaran:putar.contoh.com:443<\/code>(Jika dikonfigurasi, jabat tangan TLS akan dimulai.) Untungnya, firewall mengizinkan komunikasi HTTPS pada TCP 443, sehingga koneksi TURN melalui TLS berhasil. Klien mengamankan alamat relai di server TURN,<strong>Kandidat Estafet<\/strong>Pihak lain akan mendapatkan kandidat relai (kandidat). Ini adalah &quot;kandidat virtual untuk komunikasi melalui server TURN.&quot; Sementara itu, pihak lain (pihak jarak jauh) juga akan mendapatkan kandidat relai, atau jika jaringan bebas masalah, akan mendapatkan kandidat langsung atau kandidat STUN. Bagaimanapun, jika setidaknya satu pihak memiliki kandidat relai, pihak lain dapat mencoba terhubung ke server TURN tersebut.<\/li><li><strong>Pembentukan koneksi ICE (atau kegagalan akhirnya) melalui relai:<\/strong><br>Setelah kedua peer mendapatkan kandidat yang tersedia (satu atau kedua kandidat relay dalam contoh ini), ICE menggunakannya untuk memeriksa koneksi. Komunikasi melalui server TURN dapat di-relay setelah terhubung dengan server, sehingga saluran media tetap terbuka meskipun UDP tidak terhubung langsung antar peer. Hal ini memungkinkan komunikasi video dan audio antar pengguna dimulai. Setelah koneksi terhubung, terdapat overhead TCP melalui TLS, tetapi percakapan itu sendiri tetap dimungkinkan. Sebaliknya, jika terjadi kegagalan di sini juga (misalnya, proksi perusahaan mendeteksi dan memblokir komunikasi TLS non-HTTP, atau autentikasi server TURN gagal), sayangnya, ICE akan gagal dan koneksi akan dihentikan. Aplikasi harus mendeteksi situasi ini dan memberi tahu pengguna, misalnya &quot;Koneksi gagal.&quot;<\/li><\/ol>\n\n\n\n<p>Ini adalah alur negosiasi ICE dalam lingkungan yang keras di mana UDP tidak dapat digunakan. Singkatnya, kandidat dicoba dalam urutan &quot;host \u2192 STUN \u2192 TURN&quot;, dan jika tidak berhasil, koneksi akan gagal. Penting bagi pengembang untuk memahami perilaku ini dan setidaknya menyertakan server TURN\/TURNS dalam daftar server ICE, agar komunikasi tetap dapat terjalin bahkan dalam situasi terburuk. Lebih lanjut, ketika menerima pertanyaan dari pengguna, diperlukan pemecahan masalah, seperti menyimpulkan masalah dengan lingkungan jaringan (seperti pemblokiran UDP) dari informasi seperti &quot;ICE gagal&quot; dan memeriksa apakah server TURN telah dikonfigurasi dengan benar.<\/p>\n\n\n\n<h2>Membangun dan mengonfigurasi server STUN\/TURN\/TURNS menggunakan coturn<\/h2>\n\n\n\n<p>Jika Anda ingin membuat server STUN\/TURN Anda sendiri, gunakan implementasi sumber terbuka. <strong><a href=\"https:\/\/github.com\/coturn\/coturn\" data-type=\"URL\" data-id=\"https:\/\/github.com\/coturn\/coturn\">coturn<\/a><\/strong>Penggunaan coturn merupakan hal yang umum. Coturn adalah implementasi server yang mendukung STUN dan TURN, dan tergantung pada konfigurasinya, ia juga dapat mendukung TURNS (TLS). Artikel ini menjelaskan cara menginstal coturn di server Linux dan cara membangun server yang menyediakan STUN\/TURN\/TURNS, serta poin-poin konfigurasinya. Selain itu, kami akan menjelaskan berkas konfigurasi umum (<code>turnserver.conf<\/code>) juga ditampilkan.<\/p>\n\n\n\n<h3>Instalasi dan Konfigurasi Dasar<\/h3>\n\n\n\n<h4><strong>Install<\/strong><\/h4>\n\n\n\n<p>Untuk Ubuntu atau Debian,<code>tepat<\/code>Anda dapat menginstal paket coturn dari baris perintah. Misalnya, gunakan perintah berikut untuk menginstalnya dan mengaturnya agar dimulai secara otomatis.<\/p>\n\n\n\n<div class=\"hcb_wrap\" data-no-translation=\"\"><pre class=\"prism line-numbers lang-bash\" data-lang=\"Bash\"><code># Ubuntu\/Debian\u306e\u5834\u5408\nsudo apt-get install coturn\nsudo sed -i &#39;s\/#TURNSERVER_ENABLED=1\/TURNSERVER_ENABLED=1\/&#39; \/etc\/default\/coturn\nsudo systemctl enable --now coturn<\/code><\/pre><\/div>\n\n\n\n<p>Ini akan memulai server coturn sebagai daemon. Secara default, server akan menggunakan berkas konfigurasi <code>\/etc\/turnserver.conf<\/code> Ini akan memuat berkas, dan Anda kemudian dapat mengeditnya (buat cadangan sebelum mengedit untuk berjaga-jaga).<\/p>\n\n\n\n<h4><strong>Pengaturan dasar<\/strong><\/h4>\n\n\n\n<p> <code>turnserver.conf<\/code>Sekarang, atur item berikut:<\/p>\n\n\n\n<ul><li class=\"\"><strong>wilayah dan nama server:<\/strong> Ini adalah nama domain atau pengenal server TURN. Nama ini dapat digunakan saat mengautentikasi klien WebRTC, tetapi pada dasarnya dapat berupa string apa pun. Contoh: <code>wilayah=contoh.com<\/code>,<code>nama-server=example.com<\/code>.<\/li><li class=\"\"><strong>port pendengaran:<\/strong> Nomor port UDP untuk mendengarkan TURN dan STUN. Default-nya adalah 3478.<code>mendengarkan-ip<\/code>Anda juga dapat mengikat ke NIC tertentu dengan<code>0.0.0.0<\/code>Kami menerima semuanya.<\/li><li class=\"\"><strong>port-pendengar-tls:<\/strong> Ini adalah nomor port TCP untuk mendengarkan TLS (TURNS). Umumnya, Anda akan menentukan 443 atau 5349. Contoh: <code>port-pendengaran-tls=443<\/code>.<\/li><li class=\"\"><strong>ip eksternal:<\/strong> Jika server itu sendiri berada di belakang NAT, tentukan IP globalnya sendiri (ini memungkinkan server mengenali pemetaan antara IP internal dan IP eksternal). Hal ini tidak diperlukan jika server memiliki IP global langsung.<\/li><li class=\"\"><strong>Metode autentikasi:<\/strong> WebRTC TURN menggunakan kredensial jangka panjang,<code>lt-cred-mech<\/code>(Mekanisme Kredensial Jangka Panjang) diaktifkan.<code>pengguna=nama pengguna:kata sandi<\/code>Atur nama pengguna dan kata sandi dalam format<code>gunakan-rahasia-otorisasi<\/code>(Yang terakhir adalah autentikasi berbasis token, yang efektif untuk meningkatkan keamanan, tetapi di sini kami akan menunjukkan autentikasi pengguna statis sederhana sebagai contoh.)<\/li><li class=\"\"><strong>Pengaturan Log:<\/strong> Untuk pemecahan masalah<code>berkas log<\/code>Tentukan jalur file log di<code>bertele-tele<\/code>Anda mungkin ingin mengaktifkan pencatatan verbose.<\/li><\/ul>\n\n\n\n<h4><strong>Pengaturan firewall<\/strong><\/h4>\n\n\n\n<p>Di sisi server, untuk STUN\/TURN<strong>Port UDP 3478<\/strong>, dan untuk TURN\/TLS<strong>Port TCP 443<\/strong>(atau 5349) harus terbuka. Selain itu, relai TURN menggunakan rentang UDP 10000-20000 secara default, jadi buka juga rentang port ini di server (jika perlu).<code>pelabuhan min<\/code>dan<code>port maksimum<\/code>(Rentang dapat diubah dengan<\/p>\n\n\n\n<p>Berikut adalah daftar pengaturan yang mencerminkan pengaturan dasar di atas.<code>\/etc\/turnserver.conf<\/code>Berikut ini adalah sebuah contoh:<\/p>\n\n\n\n<div class=\"hcb_wrap\" data-no-translation=\"\"><pre class=\"prism line-numbers lang-bash\" data-lang=\"Bash\"><code># TURN\u30b5\u30fc\u30d0\u306e\u540d\u79f0\u3068\u30ec\u30eb\u30e0\uff08\u30c9\u30e1\u30a4\u30f3\uff09\nrealm=example.com\nserver-name=example.com\n\n# \u30cd\u30c3\u30c8\u30ef\u30fc\u30af\u8a2d\u5b9a\nlistening-ip=0.0.0.0           # \u3059\u3079\u3066\u306eIP\u30a2\u30c9\u30ec\u30b9\u3067\u5f85\u53d7\nexternal-ip=203.0.113.10       # \u30b5\u30fc\u30d0\u306e\u30b0\u30ed\u30fc\u30d0\u30ebIP\uff08\u5fc5\u8981\u306a\u5834\u5408\uff09\n\n# \u30dd\u30fc\u30c8\u8a2d\u5b9a\nlistening-port=3478            # STUN\/TURN\u7528 UDP\u30dd\u30fc\u30c8\ntls-listening-port=443         # TLS\u7528 TCP\u30dd\u30fc\u30c8 (443\u756a)\nmin-port=10000                 # \u4e2d\u7d99\u306b\u4f7f\u7528\u3059\u308b\u30dd\u30fc\u30c8\u7bc4\u56f2\uff08\u4e0b\u9650\uff09\nmax-port=20000                 # \u4e2d\u7d99\u306b\u4f7f\u7528\u3059\u308b\u30dd\u30fc\u30c8\u7bc4\u56f2\uff08\u4e0a\u9650\uff09\n\n# \u30ed\u30b0\u8a2d\u5b9a\nlog-file=\/var\/log\/turnserver.log\nverbose                        # \u8a73\u7d30\u30ed\u30b0\u3092\u6709\u52b9\u5316\nfingerprint                    # \u30d1\u30b1\u30c3\u30c8\u306bfingerprint\u5c5e\u6027\u3092\u4ed8\u4e0e\n\n# \u8a8d\u8a3c\u8a2d\u5b9a\uff08\u9577\u671f\u8a8d\u8a3c\u65b9\u5f0f\uff09\nlt-cred-mech                   # \u9577\u671f\u8a8d\u8a3c\u3092\u6709\u52b9\u5316\nuser=webrtcuser:secretpass123  # \u30e6\u30fc\u30b6\u540d:\u30d1\u30b9\u30ef\u30fc\u30c9 \u3092\u8a2d\u5b9a\n\n# TLS\/SSL\u8a3c\u660e\u66f8\u306e\u6307\u5b9a\ncert=\/etc\/letsencrypt\/live\/example.com\/fullchain.pem   # \u30b5\u30fc\u30d0\u8a3c\u660e\u66f8\npkey=\/etc\/letsencrypt\/live\/example.com\/privkey.pem     # \u79d8\u5bc6\u9375<\/code><\/pre><\/div>\n\n\n\n<p>Pada gambar di atas, domain<code>contoh.com<\/code>Kami memperoleh sertifikat Let&#039;s Encrypt dan menggunakannya untuk konfigurasi TLS.<code>lt-cred-mech<\/code>Aktifkan autentikasi jangka panjang dengan<code>pengguna<\/code>Otentikasi nama pengguna dan kata sandi sederhana dikonfigurasi menggunakan<code>gunakan-rahasia-otorisasi<\/code>dan<code>rahasia-otorisasi-statis<\/code>Metode yang disarankan adalah menggunakan metode berbasis token untuk menerbitkan kredensial sementara, tetapi kami tidak akan membahasnya di sini.<\/p>\n\n\n\n<h4><strong>Tindakan pencegahan saat menggunakan TLS<\/strong><\/h4>\n\n\n\n<p>Saat menjalankan Coturn pada port 443, Anda perlu berhati-hati dengan izin port di lingkungan Linux. Port di bawah 1024 disebut port istimewa dan biasanya tidak dapat dibuka tanpa hak akses root. Paket coturn Ubuntu secara default menggunakan<code>tukang putar<\/code>Karena dijalankan oleh pengguna, port 443 tidak dapat diikat sebagaimana adanya.<code>\/etc\/default\/coturn<\/code>Ubah pengguna yang berjalan menjadi root, atau<code>setcap<\/code>Dengan perintah<code>tukang putar<\/code>ke file yang dapat dieksekusi<code>cap_net_bind_service<\/code>Ada beberapa cara untuk memberikan izin. Misalnya, dalam kasus terakhir,<code>sudo setcap cap_net_bind_service=+ep \/usr\/bin\/turnserver<\/code>Dengan menjalankan perintah ini, Anda dapat mengikat port bernomor rendah meskipun Anda bukan pengguna root. Selain itu, harap tentukan jalur yang benar ke berkas sertifikat (cert\/pkey) dan atur izin berkas agar pengguna coturn dapat membacanya. Setelah mengubah pengaturan,<code>sudo systemctl restart coturn<\/code>Mulai ulang layanan dan periksa log untuk melihat apakah ada kesalahan.<\/p>\n\n\n\n<h4><strong>Pemeriksaan operasi<\/strong><\/h4>\n\n\n\n<p>Setelah memulai server Coturn, kami akan mengujinya menggunakan klien STUN untuk memeriksa operasinya, lalu mencoba menghubungkan ke ICE dari aplikasi WebRTC di peramban.<code>klien yang menakjubkan<\/code>memerintah(<code>apt-get install stun-client<\/code>(Dapat dipasang di<code>stunclient &lt;IP server&gt; 3478<\/code>Anda dapat mencoba mendapatkan IP eksternal Anda dengan menjalankan perintah berikut. Selain itu, di peramban Anda, kandidat ICE akan tercantum dalam log alat pengembang, jadi<code>srflx<\/code>(Server Refleksif) kandidat dan<code>menyampaikan<\/code>Silakan periksa apakah Anda mendapatkan kandidat. Jika tidak, coba langkah-langkah pemecahan masalah berikut:<\/p>\n\n\n\n<ul><li class=\"\">Apakah port yang diperlukan terbuka dalam pengaturan firewall server (iptables dan grup keamanan cloud)?<\/li><li class=\"\">Apakah URI, port, dan informasi autentikasi yang benar ditetapkan dalam pengaturan server ICE sisi klien (dijelaskan di bawah)?<\/li><li class=\"\"><code>turnserver.conf<\/code>dari<code>dunia<\/code>Periksa apakah pengaturannya cocok dengan autentikasi klien (ini biasanya tidak menjadi masalah pada versi WebRTC browser, karena secara otomatis menetapkan wilayah, tetapi berhati-hatilah jika Anda memiliki implementasi khusus).<\/li><li class=\"\">catatan coturn (<code>\/var\/log\/turnserver.log<\/code>) dan periksa apakah ada kesalahan otentikasi (<code>PENGGUNA YANG SALAH<\/code>Jika terjadi kesalahan seperti di atas, nama pengguna\/kata sandi tidak cocok.<\/li><\/ul>\n\n\n\n<p>Dengan pengaturan di atas, Anda akan memiliki server STUN\/TURN\/TURNS Anda sendiri yang berjalan dan akan dapat mendukung koneksi WebRTC di berbagai lingkungan jaringan.<\/p>\n\n\n\n<h2>Contoh konfigurasi server ICE untuk klien WebRTC (JavaScript)<\/h2>\n\n\n\n<p>Untuk benar-benar menggunakan server STUN\/TURN yang baru saja kita buat di aplikasi WebRTC (browser),<strong>Pengaturan Server ICE<\/strong>Dalam API WebRTC JavaScript,<code>Koneksi RTCPeer<\/code>Anda dapat menentukan daftar server STUN\/TURN saat membuat file . Di bawah ini, kami akan menunjukkan contoh kode konkret yang menentukan semua server STUN\/TURN\/TURN dan menjelaskan artinya.<\/p>\n\n\n\n<p>Pertama, buat objek konfigurasi untuk server ICE.<code>turn.example.com<\/code>(Ganti sebagaimana mestinya) STUN tidak memerlukan autentikasi, jadi tentukan saja URI-nya, tetapi TURN\/TURNS memerlukan autentikasi, jadi tentukan juga nama pengguna dan kata sandinya.<\/p>\n\n\n\n<div class=\"hcb_wrap\" data-no-translation=\"\"><pre class=\"prism line-numbers lang-js\" data-lang=\"JavaScript\"><code>const iceConfig = {\n  iceServers: [\n    \/\/ 1. STUN\u30b5\u30fc\u30d0\uff08UDP\/3478\uff09\n    { urls: &#39;stun:turn.example.com:3478&#39; },\n    \/\/ 2. TURN\u30b5\u30fc\u30d0\uff08UDP\/443\u7d4c\u7531\uff09\n    { urls: &#39;turn:turn.example.com:443?transport=udp&#39;, username: &#39;webrtcuser&#39;, credential: &#39;secretpass123&#39; },\n    \/\/ 3. TURN\u30b5\u30fc\u30d0\uff08TCP\/443 + TLS = TURNS\uff09\n    { urls: &#39;turns:turn.example.com:443&#39;, username: &#39;webrtcuser&#39;, credential: &#39;secretpass123&#39; }\n  ]\n};\nconst pc = new RTCPeerConnection(iceConfig);<\/code><\/pre><\/div>\n\n\n\n<p>Di atas<code>server es<\/code>Susunan tersebut memiliki tiga entri.<\/p>\n\n\n\n<ol><li class=\"\"><strong>TERKEJUT:<\/strong> <code>setrum:putar.contoh.com:3478<\/code><br>Menentukan alamat server STUN Anda sendiri (jika nomor port dihilangkan, 3478 akan digunakan). STUN digunakan untuk menentukan traversal NAT dan mendapatkan kandidat. Peramban akan terlebih dahulu meminta server ini melalui UDP untuk mendapatkan kandidat Server Reflexive.<\/li><li class=\"\"><strong>BELOK (UDP):<\/strong> <code>putar:putar.contoh.com:443?transportasi=udp<\/code><br>Server TURN Anda sendiri<strong>Port UDP 443<\/strong>Ini adalah pengaturan yang akan digunakan. Nama pengguna yang ditetapkan di coturn sebelumnya sebagai informasi autentikasi.<code>pengguna webrtcuser<\/code>dan kata sandi<code>secretpass123<\/code>Parameter kueri telah ditetapkan.<code>?transportasi=udp<\/code>Dengan menambahkan ini, koneksi TURN akan dicoba melalui UDP (jika tidak ditentukan, peramban akan mencoba UDP terlebih dahulu, dan jika gagal, akan mencoba TCP juga). Dengan pengaturan ini, meskipun koneksi langsung melalui STUN normal gagal, Anda akan memiliki kandidat untuk relai TURN pada port UDP 443.<\/li><li class=\"\"><strong>TURN (TLS\/TCP):<\/strong> <code>putaran:putar.contoh.com:443<\/code><br><strong>PUTAR dengan TLS<\/strong>, yaitu pengaturan server TURNS. Nama pengguna dan kata sandi juga ditentukan di sini. Peramban akan membuat koneksi TLS ke entri ini pada port TCP 443 untuk mendapatkan kandidat relai TURN. Ini adalah kandidat relai pilihan terakhir, dan meskipun komunikasi melalui UDP tidak memungkinkan sama sekali, ada peluang untuk membangun komunikasi jika kandidat ini tersedia.<\/li><\/ol>\n\n\n\n<p><code>Koneksi RTCPeer<\/code>Setelah agen ICE menghasilkan srflx, agen tersebut mencoba terhubung ke server ICE yang ditentukan untuk mengumpulkan kandidat. Agen ICE pertama-tama mendapatkan kandidat STUN (srflx), kemudian mendapatkan kandidat TURN (relai) secara paralel. Algoritme ICE kemudian menggabungkan kandidat-kandidat ini, melakukan pemeriksaan koneksi, dan memilih rute optimal. Pengembang tidak perlu terlalu memahami prosedur lebih lanjut.<\/p>\n\n\n\n<p><strong>titik:<\/strong> Seperti yang disebutkan di atas<strong>Siapkan beberapa kandidat<\/strong>penting. Misalnya,<code>setrum:<\/code>Jika Anda hanya menentukan TURN (UDP), tidak akan ada kandidat yang ditemukan di lingkungan yang memblokir UDP, dan koneksi akan gagal. Demikian pula, jika Anda hanya menentukan TURN (UDP), koneksi akan gagal di lingkungan yang hanya mengizinkan TCP. Oleh karena itu, jika memungkinkan,<code>berbelok:<\/code>dan<code>berubah:<\/code>Dengan menyertakan keduanya di server ICE, redundansi tercapai sehingga setidaknya satu kandidat valid dapat ditemukan di lingkungan apa pun (tentu saja, server TURN juga harus mendukung UDP dan TCP\/TLS). Klien (peramban) akan secara otomatis memilih jalur yang tersedia, sehingga urutan daftar bukan masalah besar. Jika saya harus mengatakan,<code>Kebijakan Transportasi Es<\/code>dari<code>menyampaikan<\/code>Kecuali Anda menentukan ini, peramban akan memprioritaskan koneksi langsung, jadi jika Anda memasukkan entri STUN, Anda akan terhindar dari penggunaan server TURN yang tidak perlu. Selain itu, jika Anda memasukkan server yang tidak relevan (seperti alamat yang tidak ada) dalam daftar server ICE, ada kemungkinan penundaan karena menunggu batas waktu, jadi sebaiknya hanya masukkan server yang Anda yakini tersedia.<\/p>\n\n\n\n<p>Terakhir, jalankan aplikasi WebRTC dengan pengaturan ini diterapkan dan verifikasi status koneksi.<code>koneksi rekan.getStats()<\/code>atau<code>chrome:\/\/webrtc-internals<\/code>Anda dapat memeriksa Kandidat ICE dan status koneksi di Chrome. Jika berfungsi seperti yang diharapkan, koneksi akan otomatis kembali ke koneksi langsung (P2P) di lingkungan yang menyediakan UDP, dan ke koneksi melalui TURN\/TLS di lingkungan yang sulit.<\/p>\n\n\n\n<h2>Perbedaan antara SFU dan TURN<\/h2>\n\n\n\n<p>Relai WebRTC secara umum dapat dibagi menjadi &quot;TURN&quot; dan &quot;SFU&quot;, tetapi peran, konfigurasi, dan penggunaannya sangat berbeda. Di sini, kami akan menjelaskan perbedaan teknisnya.<\/p>\n\n\n\n<h3>TURN: Relay sebagai alternatif peer-to-peer<\/h3>\n\n\n\n<p>TURN (Traversal Menggunakan Relay di Sekitar NAT) adalah server relai tambahan yang digunakan di lingkungan yang tidak memungkinkan komunikasi WebRTC P2P. Server TURN bertindak sebagai relai antar-peer, merelai paket terutama ketika STUN tidak berfungsi karena NAT atau firewall. Karena setiap peer mengirimkan aliran secara individual ke mitra komunikasinya masing-masing, konfigurasinya pada dasarnya adalah mesh, dan TURN diposisikan sebagai &quot;pinch hitter&quot;.<\/p>\n\n\n\n<ul><li><strong>komposisi<\/strong>:Setiap pengguna saling mengirim melalui relay (secara efektif berupa mesh)<\/li><li><strong>Skalabilitas<\/strong>: Rendah (semakin banyak orang, semakin besar bebannya)<\/li><li><strong>Konten siaran<\/strong>: Hanya transfer paket sederhana, tidak ada analisis atau pengoptimalan media<\/li><\/ul>\n\n\n\n<h3>SFU: Relai efisien untuk panggilan multi-pihak<\/h3>\n\n\n\n<p>SFU (Selective Forwarding Unit) adalah server relai cerdas yang digunakan dalam konferensi web multi-peserta.<span class=\"swl-marker mark_blue\">Setiap klien mengirimkan satu aliran ke SFU, yang secara selektif meneruskannya ke peserta lain.<\/span>Ia juga melakukan deteksi pembicara, penyesuaian kualitas gambar, dan pengoptimalan latensi, yang memungkinkan penyiaran berskala dan berkinerja tinggi.<\/p>\n\n\n\n<ul><li><strong>komposisi<\/strong>: Tipe bintang di mana setiap klien terhubung ke satu SFU<\/li><li><strong>Skalabilitas<\/strong>:Mahal (hanya satu transmisi meskipun jumlah orang bertambah)<\/li><li><strong>Konten siaran<\/strong>:Kontrol tujuan transfer dan optimasi media dimungkinkan<\/li><\/ul>\n\n\n\n<h3>Bagan perbandingan TURN vs SFU<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><th>Fitur<\/th><th>BERBELOK<\/th><th>SFU<\/th><\/tr><tr><td>Tujuan<\/td><td>Alternatif ketika traversal NAT tidak memungkinkan<\/td><td>Komunikasi multi-orang secara real-time<\/td><\/tr><tr><td>Konfigurasi Komunikasi<\/td><td>Mesh (saling mengirimkan)<\/td><td>Tipe bintang (transmisi tunggal)<\/td><\/tr><tr><td>Fungsi relai<\/td><td>Relai sederhana (transparan)<\/td><td>Penerusan dan pengoptimalan selektif tersedia<\/td><\/tr><tr><td>Skalabilitas<\/td><td>rendah<\/td><td>mahal<\/td><\/tr><tr><td>Kontrol Media<\/td><td>tidak ada<\/td><td>Ya (misalnya deteksi speaker, penyesuaian resolusi)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>TURN hanyalah &quot;pilihan terakhir ketika komunikasi P2P tidak memungkinkan,&quot; dan merupakan relai yang melengkapi jaringan P2P.<span class=\"swl-marker mark_blue\">SFU adalah arsitektur relai yang dirancang agar efisien sejak awal untuk panggilan multi-pihak.<\/span>Karena peran keduanya pada dasarnya berbeda, penting untuk merancangnya tanpa membingungkan keduanya.<\/p>\n\n\n\n<h2>ringkasan<\/h2>\n\n\n\n<p>Artikel ini memberikan penjelasan terperinci bagi pengguna WebRTC tingkat menengah hingga mahir tentang perbedaan teknis antara STUN, TURN, dan TURNS, serta contoh cara membangun server menggunakan coturn dan bagaimana ICE berperilaku di lingkungan jaringan yang keras.<\/p>\n\n\n\n<p><strong>TERKEJUT<\/strong>ringan dan memungkinkan komunikasi langsung di lingkungan NAT,<strong>BERBELOK<\/strong>menyediakan jalur komunikasi dalam situasi sulit, dan<strong>BERPUTAR<\/strong>Dengan menggabungkan semuanya, ini membuka jalan bagi WebRTC untuk digunakan dalam lingkungan khusus seperti dalam sebuah perusahaan.<\/p>\n\n\n\n<p>Masing-masing memiliki kelebihan dan kekurangannya sendiri, jadi idealnya Anda harus terhubung langsung dengan STUN bila memungkinkan, dan hanya menggunakan relai TURN bila benar-benar diperlukan. Dalam pengembangan aplikasi WebRTC yang sebenarnya, dengan menyiapkan beberapa rute dalam konfigurasi server ICE seperti yang diperkenalkan di sini, dan dengan mengonfigurasi dan mengoperasikan coturn dengan benar di sisi server, Anda dapat menyediakan komunikasi waktu nyata yang stabil di berbagai lingkungan jaringan.<\/p>\n\n\n\n<p>WebRTC adalah bidang kompleks yang menggabungkan API browser dan teknologi jaringan, tetapi memahami cara kerja STUN\/TURN dan ICE sangat penting untuk menciptakan aplikasi yang andal.<\/p>\n\n\n\n<p>Kami harap Anda mempertimbangkan informasi dalam artikel ini dan mencoba mengatasi tantangan traversal NAT pada produk Anda sendiri. Dengan demikian, pengguna akan dapat menikmati komunikasi yang lancar tanpa menyadarinya berkat pemrosesan koneksi yang dirancang dengan cermat dan dilakukan di balik layar.<\/p>","protected":false},"excerpt":{"rendered":"<p>WebRTC\u3068\u306f WebRTC\uff08Web Real-Time Communication\uff09\u306f\u3001\u30d6\u30e9\u30a6\u30b6\u540c\u58eb\u3067\u30ea\u30a2 [&hellip;]<\/p>","protected":false},"author":1,"featured_media":11871,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"swell_btn_cv_data":""},"categories":[25,9,33],"tags":[],"_links":{"self":[{"href":"https:\/\/chat-messenger.com\/id\/wp-json\/wp\/v2\/posts\/11859"}],"collection":[{"href":"https:\/\/chat-messenger.com\/id\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/chat-messenger.com\/id\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/chat-messenger.com\/id\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/chat-messenger.com\/id\/wp-json\/wp\/v2\/comments?post=11859"}],"version-history":[{"count":8,"href":"https:\/\/chat-messenger.com\/id\/wp-json\/wp\/v2\/posts\/11859\/revisions"}],"predecessor-version":[{"id":11868,"href":"https:\/\/chat-messenger.com\/id\/wp-json\/wp\/v2\/posts\/11859\/revisions\/11868"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/chat-messenger.com\/id\/wp-json\/wp\/v2\/media\/11871"}],"wp:attachment":[{"href":"https:\/\/chat-messenger.com\/id\/wp-json\/wp\/v2\/media?parent=11859"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/chat-messenger.com\/id\/wp-json\/wp\/v2\/categories?post=11859"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/chat-messenger.com\/id\/wp-json\/wp\/v2\/tags?post=11859"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}