Pada artikel ini, saya akan berbagi pengalaman saya dengan teknologi WebRTC dan server media Kurento selama fase pengujian dan implementasi. Saya akan memberi tahu Anda masalah apa yang saya temui dan bagaimana saya menyelesaikannya. Saya tidak akan berbicara tentang cara mengembangkan aplikasi dari awal, tetapi saya akan memberikan banyak tautan yang bermanfaat. Saya yakin kisah saya akan bermanfaat bagi mereka yang akan bekerja dengan WebRTC.
Pendahuluan
Sistem Informasi Medis (SIM), yang sedang dikembangkan oleh perusahaan kami, telah berkembang menjadi proyek perusahaan besar dengan banyak layanan mikro, bus pengiriman pesan, klien seluler, dan sebagainya. Beberapa bagian dari sistem harus diberikan untuk pengembangan dan dukungan kepada organisasi pihak ketiga, karena mereka bukan profil kami.
Layanan Telemedicine adalah salah satu modul SIM tersebut. Tidak ada pengalaman dalam mengembangkan konferensi video dan menggunakan WebRTC dan pesanan didelegasikan. Tetapi setelah beberapa waktu, karena berbagai keadaan, perusahaan ini berhenti mendukung konferensi video. Tanpa dukungan, layanan ini dinonaktifkan dan “mengumpulkan debu” di repositori.
Dan sekarang saatnya untuk menghidupkan kembali layanan mikro ini. Diputuskan untuk mencoba me-restart Telemedicine sendiri. Perusahaan kami telah berkembang, semakin banyak spesialis yang muncul - mungkin dan perlu untuk menguasai topik baru untuk pengembangan. Saya belum pernah terlibat dalam transmisi video sebelumnya, tetapi sangat menarik untuk memahami dan mempelajari teknologi yang menjanjikan seperti WebRTC.
Berikut adalah beberapa tautan yang sangat berguna pada teknologi WebRTC dan server Kurento yang membantu saya pada awalnya:
Memulai
Tugasnya sederhana: untuk memulihkan sistem konferensi video yang ada, untuk menginventarisasi apa yang telah dilakukan sebelumnya dan, jika perlu, memodifikasinya sesuai dengan keinginan pengguna. Tes pertama pada mesin virtual dan komputer nyata berhasil. Tetapi penyebaran sistem pada klien membawa banyak masalah.
Biarkan saya mengingatkan Anda bahwa klien sudah memiliki sistem informasi medis (SIM) yang mencakup sejumlah besar tugas: dari antrian elektronik, tempat kerja dokter, manajemen dokumen dan PAC ke subsistem manajemen peralatan medis.
Ketika menjadi perlu untuk mengembangkan fungsi konferensi video untuk komunikasi antara tenaga medis dari pusat diagnostik (selanjutnya disebut DC) dan pasien jarak jauh, dua prasyarat ditetapkan:
Semua konferensi harus direkam dan disimpan di server.
Pasien tidak boleh menginstal program tambahan apa pun pada perangkat mereka, kecuali untuk browser, yang dalam kebanyakan kasus sudah diinstal sebelumnya.
WebRTC berfungsi dari browser tanpa program atau plugin tambahan. Dan Kurento bisa merekam semua yang melewatinya. Selain itu, server media ini memiliki set perpustakaan siap pakai yang baik untuk bekerja dengan API-nya melalui Java dan JavaScript, yang sangat menyederhanakan pengembangan.
Pengembangan bagian server, atau lebih tepatnya basisnya, bahkan sebelum saya memulai tugas, dipindahkan oleh klien ke perusahaan outsourcing ke perusahaan pihak ketiga. Jadi ada "Managing Server" (CSS) - basis server siap pakai, yang saya dapatkan untuk implementasi.
Ide umum interaksi awalnya tampak seperti ini:
Tetapi dalam proses kerja lebih lanjut, seluruh sistem telah berubah dan menjadi lebih rumit.
Pengalaman resusitasi pertama
Setelah ditempatkan di jaringan uji pada mesin virtual dan beberapa komputer "hidup", banyak tes dan percobaan dilakukan - semuanya bekerja dengan sempurna. Oleh karena itu, saatnya telah tiba untuk memperkenalkan jaringan kerja yang nyata.
Untuk pengujian, seorang korban yang bertanggung jawab dalam bentuk dokter dan tempat kerjanya ditugaskan untuk membantu saya. Dan panggilan kedua melalui layanan telemedicine microsoft jatuh!
Bagus bahwa ini terjadi selama tes beta, dan selain saya dan seorang dokter yang senang dengan petualangan, tidak ada yang melihat ini.
Apa yang terjadi dan mengapa koneksi tidak dilakukan sangat sulit untuk dipahami. WebRTC tidak menunjukkan kegagalan - hanya menunggu sinyal muncul. Tanpa sadar, itu sangat sulit untuk di-debug entah bagaimana: bagian server bekerja dengan baik, Kurento diam di log, klien menunggu aliran, tetapi tidak ada yang terjadi.
Habr membantu (pujian baginya):
Sangat disayangkan bahwa saya tidak tahu alat ini sebelumnya.
Setelah menganalisis data log dan mengamati status koneksi, menjadi jelas bahwa skrip sisi dan server klien tidak bereaksi terhadap peristiwa dalam sistem WebRTC. Dan dari mana mendapatkan acara ini?
Pengembang server kurento menyediakan perpustakaan JavaScript yang sangat nyaman untuk bekerja dengan WebRTC: kurento-utils.js.
Untuk memulai dengan cepat, cukup buat objek:
new kurentoUtils.WebRtcPeer.WebRtcPeerRecvonly(options, callback());
Dan untuk mengakses acara, perlu mendefinisikan kembali metode internal perpustakaan. Saya menyederhanakan kode sebanyak mungkin untuk membuatnya lebih jelas:
Berbicara tentang sertifikat
Karena artikel ini tentang pengalaman saya, saya akan berbagi informasi bahwa browser modern telah menjadi sangat ketat tentang keamanan. Jika sumber daya memiliki sertifikat yang ditandatangani sendiri, maka bahkan dengan izin khusus, browser melarang akses ke periferal komputer.
Anda dapat membuat sertifikat sumber daya gratis di Internet dan mengkonfigurasi jaringan lokal untuk penggunaannya, atau Anda dapat mengunduh Firefox versi 65 atau lebih tinggi. Dalam versi ini, cukup klik tombol, yang saya setuju dengan risiko sertifikat yang ditandatangani sendiri dan akses kamera dan mikrofon.
Cara ini sepertinya lebih mudah bagi saya.
Tes kedua (sudah hati-hati)
Menurut saya dokter akan mencalonkan popcorn ketika dia melihat saya dalam tes berikutnya. Dia jelas menikmati melihat saya berjuang dengan teknologi modern.
Sebenarnya, pembaruan sistem ini bukan rilis, karena saya tidak memperbaiki apa pun, saya bahkan tidak tahu penyebab masalahnya. Saya ulangi bahwa semuanya bekerja dengan sempurna di kantor. Kode menambahkan reaksi ke semua peristiwa yang menghasilkan WebRTC dan Kurento, yang saya raih, dan semua ini ditulis dengan sangat rinci dalam log. Saya bahkan meletakkan log saya di file terpisah sehingga mereka tidak akan bingung dengan yang utama di IIA.
Bersama dengan seorang dokter yang tajam dan administrator sistem klien, kami mencoba sistem tersebut. Mereka bahkan tidak menguji, yaitu, "disiksa". Kami membuat konferensi video dalam semua mode yang memungkinkan dan dari semua perangkat yang tersedia. Dokter lain dan sebagian staf dari kantor jauh terlibat dalam permainan ini.
Hal utama adalah bukan untuk memeriksa sistem (tidak berfungsi), tetapi untuk mengumpulkan data sebanyak mungkin. Hasilnya, ternyata:
- Sekitar 80% upaya untuk membuat konferensi video berhasil.
- Beberapa koneksi yang menggunakan kandidat ICE untuk IPv6 tidak berfungsi.
- Dari 5 operator seluler, hanya 2 yang berfungsi.
Semuanya ternyata sederhana - Anda tidak bisa pergi jauh di Google sendiri
Analisis informasi yang dikumpulkan menunjukkan bahwa koneksi melalui server TURN dari Google tidak stabil. Entah bebannya besar, atau itu hanya server demo untuk mereka yang baru mulai mempelajari teknologinya. Tetapi sebagai fakta: kegagalan sangat sering. Butuh server TURN / STUN Anda sendiri!
Alasan kedua untuk kegagalan ini adalah alamat IPv6.local. Server kurento tidak menerima kandidat ICE dengan alamat ini. Ada baiknya bahwa sebelum mengirim semua kandidat ICE, lihat kode di tangan saya dan saya baru saja menyaring IPv6.local.
Masalah operator seluler diselesaikan, lagi-lagi, dengan server TURN / STUN.
Dalam tiga dari lima operator seluler, NAT simetris, dan WebRTC tidak dapat menerobos. Lebih detail dapat ditemukan di sini:
Apakah Symmetric NAT mengerikan?Sayang sekali ponsel pribadi saya bekerja pada kartu SIM operator yang tidak peduli dengan perlindungan simetris. Karena itu, pengujian awal saya tidak mengungkapkan masalah ini.
TURN / STUN server
Paket resiprocate-turn-server dipilih sebagai servernya.
Mereka tidak memilih untuk waktu yang lama - itu berada di repositori standar ubuntu - instalasi mudah dan pembaruan otomatis. Tetapi sangat tidak nyaman untuk terhubung dengan akun: login dan kata sandi hanya diambil dari file, itulah sebabnya Anda harus membuat utilitas atau skrip tambahan untuk mengekspor dari database server utama.
Saat ini, file ini dibuat dengan tangan dan akun didistribusikan melalui kumpulan kata sandi sederhana. Otorisasi diimplementasikan melalui server utama MIS, sehingga keamanan tidak terganggu. Tetapi struktur keseluruhan dari keseluruhan sistem terlihat jelek. Rencana untuk memperbaharui momen ini.
Perjalanan ketiga ke klien
Saya memperbaiki kode, menginstal dan mengkonfigurasi server TURN / STUN, mengembangkan kumpulan kata sandi dan membagikannya kepada klien pada awal konferensi video, dan, setelah memperbarui server produksi, saya pergi ke dokter yang sudah saya kenal.
Itu berhasil! Hore! Semua konferensi dimulai dengan sukses dari semua perangkat dan dalam semua mode: pasien dari akun pribadi dapat menghubungi dokter, terapis selama resepsi dapat menghubungi diagnosa fungsional untuk konsultasi tambahan, dan dokter sendiri dapat mengatur konferensi video multi-pengguna dari cabang berbeda dari seluruh kota.
Sudah diajarkan oleh pengalaman pahit, kami terlibat dalam pengujian yang teliti dengan penciptaan buatan situasi darurat. Dari topik artikel ini, saya menyoroti kebutuhan untuk menetapkan batas waktu tunggu koneksi. WebRTC, bersama dengan Kurento, sedang menunggu siaran untuk memulai tanpa batas lama dan berharap bahwa byte video akan segera pergi. Saya harus mengatur timer selama 10 detik, yang memberikan kesalahan pada server pengelola jika byte tidak pernah tiba.
Setelah semua perbaikan
Akhirnya, sistem berfungsi dan bekerja dengan baik. Ulasan pertama dikirim dari pengguna di lapangan. Dan segera sejumlah besar keinginan dan saran untuk desain, fungsi tambahan dan rencana lain untuk pengembangan lebih lanjut muncul. Pekerjaan mulai mendidih dengan semangat baru!
Sekarang topologi sistem lengkap terlihat seperti ini:
HASIL:
Kesimpulannya, saya ingin mengatakan yang berikut:
Pertama, WebRTC adalah teknologi luar biasa dengan prospek bagus, tetapi sangat sulit untuk menguji dan men-debug-nya. Sebelum memulai pengembangan, sangat penting untuk menggunakan jaringan dengan semua jenis koneksi yang mungkin dimiliki klien. Dan debugging melalui jendela informasi browser bukanlah alat yang sangat nyaman.
Kedua, pujilah Habru! Saat mengerjakan proyek ini, saya menemukan banyak informasi tentang sumber ini. Semua tautan dalam artikel ini mengarah ke sana.
Diputuskan untuk meninggalkan proyek konferensi video Telemedicine untuk dukungan dan pengembangan di organisasi kami, kami tidak akan melakukan outsourcing. Di masa depan, masih banyak pekerjaan:
SEGALA SESUATU
Saya yakin pengalaman saya akan berguna tidak hanya untuk pengembang di bawah WebRTC + Kurento, tetapi juga bagi mereka yang akan mulai menerapkan proyek yang sama rumitnya. Lebih memperhatikan pengujian dalam kondisi sedekat mungkin dengan kenyataan.
Dan memperhitungkan risiko bahwa tim pendukung untuk layanan microser Anda dapat tiba-tiba "menghilang" - ini adalah tugas yang sangat tidak terduga dan tidak menyenangkan.