Menerbitkan aliran kamera: RTSP dan HLS bukan tepi yang sama

Anda membuka satu port kamera, mengarahkan pemutar ke port itu, dan menganggap masalah internet sudah selesai. Lalu ponsel tidak bisa memutarnya, peramban tidak bisa memutarnya, dan halaman administrasi kamera hanya berjarak satu jalur yang salah ketik dari tepi publik. Model pengiriman yang Anda pilih, RTSP atau HLS, menentukan sebagian besar hal itu sebelum satu aturan firewall pun ditulis. VPN hanya menyediakan segmen privat.

VPN memperbaiki jalur sumber, bukan jalur penonton

VPS yang terhubung ke LAN kamera melalui terowongan dapat menjangkau kamera di alamat privatnya, dan itu benar-benar berguna. Artinya kamera tidak perlu port masuk sendiri dan router rumah tetap tertutup. Itu tidak memberi tahu Anda bahasa apa yang akan dipakai penonton. Pemutar desktop, peramban, ponsel, dan televisi pintar mendukung protokol yang berbeda, dan masing-masing punya ekspektasi sendiri soal TLS, autentikasi, dan codec.

Ini asumsi yang layak dibuang: menerbitkan berarti membuat sumber dapat dijangkau. Menerbitkan sebenarnya berarti memberi audiens tertentu cara yang didukung untuk mengonsumsi media. Aliran yang diterbitkan punya format, audiens, dan kredensial; kamera yang dapat dijangkau tidak punya satu pun dari itu. Keterjangkauan adalah bagian yang dipecahkan terowongan, dan titik masuk penonton adalah bagian yang masih harus Anda rancang.

RTSP adalah negosiasi, bukan satu port

RTSP membawa kendali sesi: klien meminta deskripsi, menyiapkan satu atau beberapa jalur media, lalu memutar. Transportasi medianya sendiri dinegosiasikan selama penyiapan itu, karena itu protokolnya tidak tergambar baik oleh satu port TCP yang diteruskan. Negosiasi itulah bagian yang dilewatkan orang saat membandingkan aturan firewall.

Bergantung pada titik akhir, RTP dapat datang di port UDP terpisah atau diselipkan pada koneksi kendali. Relay yang hanya meneruskan port 554 dan menganggap sisanya akan bekerja biasanya menghasilkan sesi yang terhubung, melaporkan satu jalur, lalu tidak menampilkan apa pun. Periksa transportasi yang benar-benar dinegosiasikan kamera Anda sebelum menulis aturan untuknya. Penangkapan di sisi privat menjawabnya dalam satu menit, dan menebak menelan biaya satu malam.

Untuk audiens kecil dan dikenal dengan pemutar yang kompatibel, relay RTSP yang dikonfigurasi dengan sengaja bisa jadi jawaban yang tepat. Batasi sumber mana yang boleh ditariknya dan wajibkan autentikasi di relay. Catat pemutar yang Anda uji, karena aliran RTSP yang bekerja di VLC masih bisa gagal di peramban.

HLS adalah daftar putar plus sumber daya

Penonton HLS mengambil daftar putar, lalu mengambil segmen media yang disebutkan daftar itu. Spesifikasi HLS mendefinisikan model sumber daya itu, dan detail operasional pentingnya adalah daftar putar merujuk ke URL lain. Rujukan relatif diselesaikan terhadap lokasi daftar putar, jadi proxy yang menulis ulang jalur harus menulis ulangnya secara konsisten.

Jika kamera sudah menyajikan HLS yang bisa dipakai, frontend publik dapat meneruskan permintaan daftar putar dan segmen itu melalui terowongan. Perhatikan kunci, pengalihan, dan URL yang dihasilkan aplikasi. URL absolut apa pun yang menunjuk ke host privat akan rusak begitu penonton di luar LAN mengikutinya. Jalur relatif adalah yang bertahan dari penulisan ulang proxy, jadi utamakan itu di mana pun Anda mengendalikan keluaran yang dihasilkan.

Jika kamera hanya berbicara RTSP, sesuatu harus mengubah sumber ke format penonton. Pengemasan ulang dan transcoding adalah pekerjaan berbeda: pengemasan ulang mempertahankan codec, sedangkan transcoding mengodekan ulang demi kompatibilitas, dan hanya yang kedua memakan CPU serius. Keduanya tidak menjadi perlu hanya karena ada VPN di jalur.

Rencanakan tautan unggah berdasarkan tempat distribusi terjadi. Satu ingest privat yang memasok layanan media publik berperilaku sangat berbeda dari setiap penonton yang menarik alirannya sendiri melalui terowongan. Pola kedua biasanya berakhir pada koneksi rumah yang jenuh dan kamera yang tampak gagal secara acak.

Letakkan autentikasi di tepi yang Anda terbitkan

TLS, autentikasi penonton, dan pencatatan akses termasuk pada titik masuk publik, bukan pada kamera. Ini menjaga kredensial kamera terpisah dari kredensial aliran. Ini juga memberi Anda satu tempat untuk mencabut akses ketika anggota audiens pergi. Menaruh kendali itu di kamera justru berarti setiap perubahan audiens menjadi perubahan administratif pada perangkat yang seharusnya tidak pernah dapat dijangkau publik.

Jaga VPN dan izin administrasi kamera terpisah dari jalur penerbitan. VPS yang dapat menjangkau antarmuka web kamera untuk menarik aliran tidak seharusnya juga menjadi mesin yang memaparkan antarmuka itu. Audiens tidak boleh pernah mengetahui alamat kamera.

Lalu verifikasi kedua ujung yang benar-benar Anda bangun alih-alih menganggap rantainya bekerja:

$ ffprobe -v error -rtsp_transport tcp rtsp://10.50.0.9:554/stream1
$ curl -sI https://stream.example.net/live/index.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl

Pemeriksaan sumber privat yang berhasil dan pengambilan daftar putar yang berhasil di tepi publik membuktikan dua paruh berbeda dari rancangan. Uji keduanya secara terpisah. Pemutaran dari jenis klien yang sama dengan yang dipakai audiens Anda adalah satu-satunya uji yang mencakup seluruh rantai.

Yang akhirnya Anda miliki adalah rantai dengan tujuan di setiap mata rantai: sumber privat, ingest terbatas, pengemasan terpilih, pintu masuk penonton yang sah. Tidak ada mata rantai yang opsional, dan tidak ada yang tercipta dengan membuka port.