Apakah WebRTC tanpa server apa pun, bahkan server pensinyalan mungkin

Ringkasan

WebRTC adalah serangkaian komponen yang memungkinkan media real-time dan saluran data antar browser. Namun, masih membutuhkan layanan backend untuk fungsionalitas tertentu. Dalam artikel ini, kami akan mengeksplorasi alasan mengapa layanan backend diperlukan, komponen dan perangkat keras yang terlibat dalam pengaturan WEBRTC, codec audio dan video yang didukung, dan pentingnya direktori dan server stun.

1. Apa itu WEBRTC?

WebRTC adalah serangkaian komponen yang memungkinkan pengembang untuk mengatur media real-time dan saluran data antar browser. Itu dibuat oleh Google dan berisi komponen -komponen utama yang dikirim dalam Chrome, Firefox, Opera, dan Microsoft Edge (ORTC).

2. Mengapa Anda masih membutuhkan layanan backend?

Terlepas dari kemampuan WEBRTC, layanan backend diperlukan untuk fungsionalitas tertentu. Misalnya, untuk menelepon seseorang, Anda perlu mengetahui alamat mereka, yang biasanya dinamis. Informasi ini perlu disimpan dan dikelola di server. Selain itu, layanan backend dapat melacak semua perangkat untuk pengguna dan memberi tahu mereka tentang panggilan yang masuk.

3. Komponen dan perangkat keras apa yang terlibat dalam menyiapkan WebRTC?

WebRTC membantu mengatur lingkungan fisik, seperti kamera, speaker, dan mikrofon, serta perangkat keras lainnya seperti pembatalan gema dan perangkat keras pembatalan latar belakang. Ini juga membantu dalam mengkonfigurasi jaringan menggunakan stun (utilitas traversal sesi untuk nat).

4. Audio codec apa yang didukung oleh WEBRTC?

WebRTC mendukung berbagai codec audio termasuk G711, ILBC, dan Opus. Opus adalah codec variabel berkualitas tinggi yang banyak digunakan di WebRTC.

5. Video codec apa yang didukung oleh WebRTC?

WEBRTC Mendukung Codec VP8 dan VP9, ​​yang merupakan variasi bebas royalti Google dari H.264/jam.265. Itu juga mendukung h.264.

6. Mengapa codec audio penting di webrtc?

Audio codec menangani tugas seperti kehilangan paket, pengkodean dan decoding audio, koreksi kesalahan, pembatalan kebisingan, pembatalan gema, dan leveling volume. Mereka berkontribusi pada popularitas WEBRTC di perangkat seluler dan desktop.

7. Apa direktori siapa yang tersedia untuk dihubungi?

Untuk memulai panggilan, Anda perlu mengetahui alamat penerima. Direktori berfungsi sebagai halaman putih yang dinamis, memungkinkan pengguna untuk check -in dengan server dan memberikan informasi kontak. Ini dapat diimplementasikan menggunakan XMPP, SIP, atau protokol khusus.

8. Mengapa Anda membutuhkan server setrum?

Server stun (sesi traversal utilities for nat) membantu menentukan alamat IP eksternal suatu perangkat dan memeriksa apakah dua perangkat dapat berkomunikasi secara langsung. Ini memainkan peran penting dalam membangun koneksi antara teman sebaya.

9. Apa itu server giliran?

Jika sesi peer-to-peer tidak dimungkinkan karena keterbatasan firewall, diperlukan server Turn (Traversal menggunakan relay di sekitar NAT). Ini membantu dalam menyampaikan data antar perangkat dengan melewati pembatasan firewall.

10. Mengapa Anda harus mempertimbangkan menggunakan layanan backend seperti Sinch?

Menyiapkan dan memelihara server untuk pensinyalan, setrum, dan belokan bisa menjadi rumit dan mahal. Sinch, sebagai penyedia layanan backend, menawarkan solusi yang dapat diskalakan dan hemat biaya. Mereka menangani satu miliar menit per tahun dan menyediakan SDK WEBRTC yang dioptimalkan untuk perangkat dan kondisi jaringan yang berbeda.

11. Apakah WebRTC hanya tentang backend?

Tidak, WEBRTC melibatkan aspek frontend dan backend. Sinch, misalnya, menyesuaikan dan mengkonfigurasi WebRTC SDK mereka untuk memastikan kinerja yang optimal di seluruh perangkat dan kondisi jaringan. Mereka mengimplementasikan fitur seperti opus adaptif untuk menyesuaikan kualitas perekaman berdasarkan metrik kualitas dari lalu lintas.

12. Apa manfaat menggunakan Sinch?

Sinch menawarkan keahlian dalam komunikasi real-time dan menyediakan SDK WEBRTC yang disesuaikan, codec yang dioptimalkan, dan jaringan terdistribusi. Harga mereka untuk transfer data hemat biaya dan mereka memastikan komunikasi latensi rendah melalui server yang berlokasi strategis.

13. Seberapa nyata latensi jaringan dalam percakapan?

Sekitar 250ms latensi jaringan terlihat selama percakapan. Faktor -faktor seperti latensi jaringan, waktu pemrosesan, dan pengkodean data dapat berkontribusi pada latensi keseluruhan.

14. Fungsionalitas apa yang disediakan layanan backend di WebRTC?

Layanan backend menangani tugas seperti manajemen direktori, pensinyalan, stun dan manajemen server yang berbelok, dan pelacakan perangkat untuk pengguna.

15. Apa yang membuat WebRTC populer di perangkat seluler dan desktop?

Dukungan WebRTC untuk codec audio dan video, bersama dengan kemudahan penggunaan dan kemampuan real-time, berkontribusi pada popularitasnya di perangkat seluler dan desktop.

Apakah WebRTC tanpa server apa pun, bahkan server pensinyalan mungkin

Kemudian, buka dua tab di browser Anda (atau di dua browser yang berbeda), dan masukkan Localhost: 7000. Seperti yang disebutkan sebelumnya, yang terbaik adalah memiliki dua kamera yang tersedia untuk contoh ini berfungsi. Jika semuanya berjalan dengan baik, Anda akan melihat satu umpan video di setiap tab.

Webrtc dan mengapa Anda masih membutuhkan layanan backend

Bergabunglah dengan komunitas Dzone dan dapatkan pengalaman anggota penuh.

Artikel ini awalnya muncul di blog Sinch oleh Christian Jensen.

Apa itu WEBRTC?

WebRTC adalah serangkaian komponen yang berbasis dari beberapa inovasi dari perusahaan yang dibeli Google pada tahun 2010. WebRTC memungkinkan pengembang untuk mengatur media real-time dan saluran data antara dua browser (atau ponsel jika Anda mengkompilasinya untuk itu). Ini berisi beberapa komponen utama dan semuanya dikirim dalam krom, firefox, dan opera, dan versi yang ada di Microsoft’S New Browser Edge (ORTC).

Menyiapkan aliran data dan perangkat keras

WebRTC membantu mengatur lingkungan fisik (seperti kamera, speaker, dan mikrofon) dan perangkat keras lainnya (seperti pembatalan gema dan perangkat keras pembatalan latar belakang – yang Anda temukan sebagian besar di ponsel), ditambah membantu mencari tahu jaringan bersama dengan setrum dengan setrum.

Codec audio dan codec video

Salah satu manfaat utama menggunakan WEBRTC atas perangkat lunak lain saat berhadapan dengan audio dan video real-time adalah codec bebas sumber/royalti bahwa Google cukup baik untuk dikirim.

Codec audio

• G711, digunakan dalam jaringan telepon biasa
• ILBC, kode sempit tua, juga digunakan dalam jaringan telepon
• Opus, variabel berkualitas tinggi dan codec (dukungan untuk adaptif) yang merupakan codec terbaru yang digunakan di webrtc.

Ada lebih banyak dikirim, tetapi ini adalah yang utama dan yang paling banyak digunakan.

Codec video

• VP8 dan Segera VP9, ​​ini Google’S variasi royalti gratis h.264/jam.265 codec
• H.264 (ditambahkan pada 2015 sebagai perjanjian untuk ORTC)

Audio codec melakukan banyak pekerjaan untuk Anda, mengurus kehilangan paket, pengkodean dan decoding audio, koreksi kesalahan, pembatalan noise, pembatalan gema, leveling volume, dan banyak lagi. Fakta bahwa itu berisi codec juga membuatnya sangat populer di perangkat seluler dan desktop.

Jadi, sekarang saya dapat membuat panggilan berbasis browser saya sendiri di JavaScript murni menggunakan (tambahkan kerangka kerja JS sisi klien favorit Anda di sini). Sayangnya, itu’Tidak sesederhana itu untuk mengatur panggilan karena ada dua hal utama yang hilang di sini.

Direktori siapa yang tersedia untuk dihubungi (atau penemuan rekan)

Untuk menelepon seseorang, Anda perlu mengetahui alamatnya, dan tidak seperti nomor telepon biasa, alamat di internet sebagian besar adalah alamat IP yang dinamis. Untuk menyelesaikan ini, Anda harus mencatat di mana semua orang berada. Ini dapat dilakukan dalam beberapa cara menggunakan XMPP, SIP, Protokol Kustom, dll., Tapi semuanya bermuara pada siapa pun yang siap menerima panggilan check -in dengan server dengan satu atau lain cara, dan memungkinkan server tahu cara menghubungi rekan itu (tersirat untuk pengiriman lebih lanjut dari penawaran/undangan/SDP dll.).

Anggap saja sebagai halaman putih yang benar -benar dinamis. Ini biasanya dilakukan pada interval waktunya untuk menjaga firewall atau serupa terbuka untuk server pensinyalan untuk memberi tahu klien jika seseorang ingin berkomunikasi dengan mereka. Jadi, ini adalah bagian pertama yang perlu Anda bangun di atasnya.

Selanjutnya Anda mungkin ingin melacak semua perangkat untuk pengguna tertentu dan memberi tahu mereka di semua perangkat jika ada panggilan. Menggunakan Sinch, kami mengurus bagian ini untuk Anda.

Server setrum

Setelah server pensinyalan Anda menemukan perangkat dan mengirimkan penawaran, Anda memerlukan server setrum. Server STUN akan memfasilitasi untuk menentukan alamat IP eksternal Anda serta jika dua (atau lebih) perangkat dapat berbicara satu sama lain secara langsung. Sinch akan mengurus ini untuk Anda juga.

Server Relay Media (Turn Server)

Jika sesi peer-to-peer tidak dimungkinkan (data kami sendiri menyarankan akun ini untuk sekitar 25% dari sesi), Anda akan memerlukan server giliran. Turn Server pada dasarnya akan menggeser bit untuk Anda melalui lubang terbuka di firewall antara kedua klien. Mengapa ini terjadi? Yang paling umum adalah firewall asimetris dan kemungkinan untuk meninju lubang di berbagai pelabuhan di firewall.

Oke, tapi kenapa Don’T saya mengatur ini sendiri?

Nah, Anda bisa. Ini mungkin sedikit berlebihan, dan satu lagi kompetensi di tim operasi Anda akan diperlukan. Giliran dan server setrum Anda mungkin akan sangat dimanfaatkan dan mahal. Dan di sinilah ekonomi yang dapat diskalakan masuk. Karena Sinch melakukan lebih dari satu miliar menit per tahun, harga kami untuk transfer data lebih murah daripada yang bisa didapat oleh kebanyakan perusahaan.

Anda mungkin ingin memiliki jaringan terdistribusi juga. Jika Anda misalnya memiliki server giliran di u.S. Dan panggilan terjadi di antara klien di Eropa, Anda akan menambahkan latensi hanya karena semua lalu lintas perlu melintasi lautan. Aturan praktis yang baik adalah bahwa sekitar 250 ms terlihat dalam percakapan (lebih banyak kualitas info layanan di sini). Jadi, tanpa menambahkan latensi jaringan apa pun pada klien dan waktu pemrosesan untuk menyandikan data, Anda pada dasarnya dijamin memiliki terlalu banyak latensi antara klien.

Apakah ini hanya tentang backend?

Dia’S tidak hanya tentang backend. Di Sinch kami memiliki pengalaman luas tentang komunikasi waktu nyata, dan kami menyesuaikan dan mengkonfigurasi WebRTC SDK kami untuk bekerja paling baik di semua perangkat dan di berbagai kondisi jaringan yang berbeda. Beberapa contoh adalah implementasi opus adaptif, yang akan menyesuaikan kualitas perekaman berdasarkan metrik kualitas dari lalu lintas kami. Kami juga tahu codec apa yang akan digunakan dalam keadaan tertentu, dan mana yang harus dipilih untuk meminimalkan transkode dan latensi di seluruh dunia.

Diterbitkan di Dzone dengan izin Christian Jensen . Lihat artikel asli di sini.

Pendapat yang diungkapkan oleh kontributor dzone adalah milik mereka.

Apakah WebRTC tanpa server apa pun, bahkan server pensinyalan mungkin?

Saya mencoba mengatur plugin A cordova untuk iOS yang mengimplementasikan fungsi WebRTC tanpa menggunakan server mana pun dan itu akan hanya digunakan di jaringan lokal. Saya tahu ada plugin ini, yang terlihat menjanjikan tetapi saya memiliki beberapa masalah dengannya. Rencana saya bukan untuk menggunakan trun, setrum atau server pensinyalan apa pun. Mungkin Anda berpikir sekarang: “Ok ini tidak mungkin. Tidak ada pensinyalan sama dengan tidak ada koneksi.“Tapi izinkan saya menjelaskan dulu. Seperti yang ditunjukkan di sini dan di sini dimungkinkan untuk menghindari menggunakan trun, setrum atau server es. Saya pikir ini adalah cara yang baik untuk memulai proyek saya tetapi masih ada pertanyaan terbuka. Bagaimana perangkat dapat menemukan satu sama lain jika tidak ada pensinyalan jenis apa pun (dalam contoh mereka menggunakan node.JS Server)? Saat ini saya sedang bermain dengan ide kode-QR yang berisi semua informasi yang diperlukan. Pada akhirnya itu harus terlihat seperti ini (Black Arrwos lebih penting): idenya adalah bahwa setiap orang yang datang ke ruangan harus memindai kode-QR pada RP dan kemudian perangkat mengetahui IP, port, dll. dari RP dan koneksi WEBRTC dengan Datachannel akan dibuat. Saya telah mencari jawaban selama berhari -hari sekarang, tetapi karena fakta (atau setidaknya salah satu alasannya) bahwa WebRTC bahkan tidak didukung pada iOS secara asli tidak ada banyak contoh WebRTC di luar sana yang bekerja di iOS dan tidak ada seorang pun untuk jaringan lokal untuk jaringan lokal. Jadi pertanyaan saya adalah: apakah saya berada di jalan yang benar atau apakah ini tidak mungkin? (Saya tidak menemukan contoh untuk ini di mana pun, tetapi jika saya meletakkan semua posting yang saya baca bersama, saya pikir itu harus dimungkinkan.)

Ditanya 10 Agustus 2017 pukul 12:38

3.257 3 3 Lencana Emas 11 11 Lencana Perak 19 19 Lencana Perunggu

Tidak masalah bagaimana Anda memecahkan penemuan, tetapi untuk membuat koneksi WebRTC, Anda perlu mendapatkan penawaran dan menjawab pesan di antara rekan -rekan. Pesan -pesan itu secara otomatis mengandung kandidat es jika Anda menunggu pengumpulan es selesai terlebih dahulu. Lihat Stackoverflow.com/a/29056385/918910.

WEBRTC: Contoh yang berfungsi

Baru -baru ini saya harus menggunakan WEBRTC untuk proyek sederhana. Teknologi itu sendiri memiliki banyak keunggulan dan sedang dikembangkan sebagai standar terbuka, tanpa perlu plugin apa pun. Namun, saya cukup baru di WEBRTC dan memiliki beberapa masalah untuk mendapatkan konsep -konsep dasar, serta menciptakan solusi yang berfungsi. Ada banyak tutorial yang tersedia (seperti ini, yang menginspirasi solusi saya). Tetapi kebanyakan dari mereka tidak lengkap, usang, atau memaksa saya untuk menggunakan beberapa layanan pihak ketiga (e.G. Google Firebase), yang hanya membuat seluruh proses lebih rumit untuk diatur dan lebih sulit untuk dipahami.

Saya memutuskan untuk mengumpulkan informasi dari semua sumber daya itu dan membuat contoh sederhana dan berfungsi dari aplikasi WebRTC. Itu tidak memerlukan layanan pihak ketiga kecuali Anda ingin menggunakannya melalui jaringan publik (dalam hal ini memiliki server akan benar-benar membantu). Saya berharap ini akan memberikan titik awal yang baik untuk semua orang yang tertarik untuk menjelajahi WebRTC.

Ini tidak akan menjadi tutorial lengkap dari teknologi WebRTC. Anda dapat menemukan banyak tutorial dan penjelasan terperinci di seluruh internet, misalnya di sini. Anda juga dapat memeriksa API WEBRTC jika Anda ingin informasi lebih lanjut. Posting ini hanya akan menunjukkan kepada Anda satu contoh kerja yang mungkin dari WebRTC dan jelaskan cara kerjanya.

Gambaran umum

Kode sumber lengkap dari contoh ini tersedia di GitHub. Program ini terdiri dari tiga bagian:

• aplikasi web
• server pensinyalan
• Putar server

Itu aplikasi web sangat sederhana: satu file html dan satu file javascript (ditambah satu ketergantungan: stopkontak.io.JS, yang termasuk dalam repositori). Ini dirancang untuk bekerja dengan hanya dua klien (dua browser web atau dua tab dari browser yang sama). Setelah Anda membukanya di browser Anda (diuji pada Firefox 74), ia akan meminta izin untuk menggunakan kamera dan mikrofon Anda. Setelah izin diberikan, video dan audio dari masing -masing tab akan dialirkan ke yang lain.

Catatan: Anda mungkin mengalami beberapa masalah jika Anda mencoba mengakses kamera yang sama dari kedua tab. Dalam tes saya, saya’VE menggunakan dua perangkat saat menguji pada mesin saya (kamera laptop bawaan dan webcam USB).

Itu server pensinyalan digunakan oleh aplikasi WebRTC untuk bertukar informasi yang diperlukan untuk membuat koneksi langsung antara rekan. Anda dapat memilih teknologi apa pun yang Anda inginkan untuk ini. Contoh ini menggunakan websockets (Python-Socketio di backend dan stopkontak.IO-CLIENT di frontend).

Itu BERBELOK Server diperlukan jika Anda ingin menggunakan contoh ini melalui jaringan publik. Proses ini dijelaskan lebih lanjut dalam posting ini. Untuk pengujian jaringan lokal, Anda tidak akan membutuhkannya.

Pensinyalan

Server pensinyalan ditulis dalam Python3 dan terlihat seperti ini:

dari aioHttp impor web impor socketio room = 'room' sio = socketio.Asyncserver (cors_allowed_origins = '*') app = web.Application () sio.lampirkan (app) @sio.Acara Async Def Connect (Sid, Environ): Print ('Connected', Sid) Await Sio.emit ('siap', kamar = kamar, skip_sid = sid) sio.enter_room (sid, kamar) @sio.Event Def Disconnect (SID): SIO.ceave_room (sid, room) cetak ('terputus', sid) @sio.Event Async Def Data (SID, Data): Print ('Pesan dari <>: <>'.Format (Sid, Data)) menunggu sio.emit ('data', data, kamar = kamar, skip_sid = sid) if __name__ == '__main__': web.run_app (app, port = 9999)

Setiap klien bergabung dengan kamar yang sama. Sebelum memasuki ruangan, a siap Acara dikirim ke semua klien saat ini di ruangan. Itu berarti bahwa koneksi Websocket pertama tidak akan mendapatkan pesan apa pun (ruangan kosong), tetapi ketika koneksi kedua dibuat, yang pertama akan menerima a siap acara, menandakan bahwa setidaknya ada dua klien di dalam ruangan dan koneksi WebRTC dapat dimulai. Selain itu, server ini akan meneruskan data apa pun (data acara) yang dikirim oleh satu websocket ke yang lain.

Pengaturan cukup sederhana:

CD Signaling Pip Instalasi AIOHTTP Python-Socketio Python Server.py

Ini akan memulai server pensinyalan di Localhost: 9999.

WEBRTC

Proses yang disederhanakan menggunakan WEBRTC dalam contoh ini terlihat seperti ini:

• Kedua klien memperoleh aliran media lokal mereka
• Setelah aliran diperoleh, setiap klien terhubung ke server pensinyalan
• Setelah klien kedua terhubung, yang pertama menerima a siap acara, yang berarti bahwa koneksi WebRTC dapat dinegosiasikan
• Klien pertama membuat objek RTCPeerConnection dan mengirimkan penawaran ke klien kedua
• Klien kedua menerima penawaran, membuat objek RTCPeerConnection, dan mengirimkan jawaban
• Informasi lebih lanjut juga dipertukarkan, seperti kandidat es
• Setelah koneksi dinegosiasikan, panggilan balik untuk menerima aliran jarak jauh dipanggil, dan aliran itu digunakan sebagai sumber dari video elemen.

Jika Anda ingin menjalankan contoh ini di localhost, server pensinyalan dan aplikasi web adalah semua yang Anda butuhkan. Bagian utama dari file HTML adalah elemen video tunggal (sumber mana yang akan diatur nanti oleh skrip):

Bagian javascript sedikit lebih rumit, dan saya’LL jelaskan langkah demi langkah. Pertama, ada variabel konfigurasi:

// variabel konfigurasi const Signaling_server_url = 'http: // localhost: 9999'; const pc_config = <>;

Untuk localhost, Pc_config bisa tetap kosong, dan Signaling_server_url harus menunjuk ke server pensinyalan Anda’ve dimulai pada langkah sebelumnya.

Selanjutnya, kami memiliki metode pensinyalan:

Biarkan Socket = IO (Signaling_Server_url, < autoConnect: false >); stopkontak.on ('data', (data) => < console.log('Data received: ',data); handleSignalingData(data); >); stopkontak.on ('ready', () => < console.log('Ready'); createPeerConnection(); sendOffer(); >); Biarkan sendData = (data) => < socket.emit('data', data); >;

Dalam contoh ini, kami ingin terhubung ke server pensinyalan hanya setelah kami mendapatkan aliran media lokal, jadi kami perlu mengatur . Selain itu, kami memiliki file senddata metode yang memancarkan a data acara, dan kami bereaksi terhadap data acara dengan menangani informasi yang masuk dengan tepat (lebih lanjut tentang itu nanti). Juga, menerima a siap Acara berarti bahwa kedua klien telah memperoleh aliran media lokal mereka dan telah terhubung ke server pensinyalan, sehingga kami dapat membuat koneksi di pihak kami dan menegosiasikan penawaran dengan sisi jarak jauh.

Biarkan PC; Biarkan LocalStream; Biarkan RemotestreamElement = Dokumen.queryselector ('#remotestream');

Biarkan getLocalStream = () => < navigator.mediaDevices.getUserMedia(< audio: true, video: true >) .lalu ((stream) => < console.log('Stream found'); localStream = stream; // Connect after making sure that local stream is availble socket.connect(); >) .catch (error => < console.error('Stream not found: ', error); >); >

Biarkan createPeerConnection = () => < try < pc = new RTCPeerConnection(PC_CONFIG); pc.onicecandidate = onIceCandidate; pc.onaddstream = onAddStream; pc.addStream(localStream); console.log('PeerConnection created'); >Catch (kesalahan) < console.error('PeerConnection failed: ', error); >>;

Biarkan sendOffer = () => < console.log('Send offer'); pc.createOffer().then( setAndSendLocalDescription, (error) => < console.error('Send offer failed: ', error); >); >; Biarkan sendanswer = () => < console.log('Send answer'); pc.createAnswer().then( setAndSendLocalDescription, (error) => < console.error('Send answer failed: ', error); >); >; Biarkan setandsendlocaldescription = (sessionDescription) => < pc.setLocalDescription(sessionDescription); console.log('Local description set'); sendData(sessionDescription); >;

Biarkan OnicEcandidate = (event) => < if (event.candidate) < console.log('ICE candidate'); sendData(< type: 'candidate', candidate: event.candidate >); >>; Biarkan onAddStream = (event) => < console.log('Add stream'); remoteStreamElement.srcObject = event.stream; >;

Biarkan HandLesignalingData = (data) => < switch (data.type) < case 'offer': createPeerConnection(); pc.setRemoteDescription(new RTCSessionDescription(data)); sendAnswer(); break; case 'answer': pc.setRemoteDescription(new RTCSessionDescription(data)); break; case 'candidate': pc.addIceCandidate(new RTCIceCandidate(data.candidate)); break; >>;

// Mulai koneksi getLocalStream ();

CD Web Python -M HTTP.Server 7000

sudo apt menginstal coturn turningerver -a -o -v -n ---no -dtls ---no -tls -u Nama pengguna: kredensial -r RealMname

const turn_server_url = ': 3478'; const turn_server_username = 'username'; const turn_server_credential = 'kredensial'; const pc_config = < iceServers: [ < urls: 'turn:' + TURN_SERVER_URL + '?transport=tcp', username: TURN_SERVER_USERNAME, credential: TURN_SERVER_CREDENTIAL >, < urls: 'turn:' + TURN_SERVER_URL + '?transport=udp', username: TURN_SERVER_USERNAME, credential: TURN_SERVER_CREDENTIAL >]>;