Mengapa Kamera Berlabel ONVIF Tetap Gagal Integrasi

ONVIF adalah bahasa bersama yang dipakai kamera IP untuk bicara dengan NVR dan perangkat lunak. Masalahnya, tulisan "ONVIF compliant" di brosur perlu diperiksa melalui profil dan versi firmware yang tercantum dalam daftar produk ONVIF. Videonya sendiri dikirim lewat RTSP, yang punya cara gagalnya sendiri. Integrasi yang macet hampir selalu terhambat di empat tempat: profil, discovery, jalur kirim, dan setelan aliran.

Masalah ini sering baru terlihat pada jaringan lokasi pemasangan. Sebagian kamera dapat gagal tampil di sistem analitik meskipun NVR tetap merekam. Karena itu, pengujian perlu mencakup profil, pencarian perangkat, jalur video, dan konfigurasi aliran.

Label "ONVIF compliant" sebenarnya menjanjikan apa?

ONVIF membagi kemampuan perangkat ke beberapa profil. Kamera dan perangkat lunak harus mendukung profil yang sesuai untuk fungsi yang akan dipakai. Kamera dengan Profile S dan VMS yang hanya memakai Profile M sama-sama dapat berlabel ONVIF, tetapi label itu tidak membuktikan kecocokan fungsi video.

Klaim kesesuaian berlaku per profil dan per versi firmware. ONVIF memajang setiap produk yang punya Declaration of Conformance, dan per Januari 2026 jumlahnya sudah lewat 35.000 produk. Produk yang tidak ada di daftar itu hanya klaim pemasaran. "ONVIF compatible" atau "support ONVIF" biasanya berarti vendornya menerapkan sebagian profil, lalu tidak pernah mengujikannya.

Cari tipe kamera dalam daftar produk sesuai ONVIF. Catat profil dan versi firmware yang terdaftar, lalu cocokkan dengan satuan yang ditawarkan pemasok. Kesesuaian versi 5.1 belum membuktikan versi 5.4 juga tercakup.

Mengapa profil ONVIF tertua dipensiunkan, dan apa dampaknya?

ONVIF mengumumkan pada 9 Oktober 2025 bahwa dukungan Profile S akan dihentikan, dengan Profile T sebagai penggantinya. Pengujian tool rilis Juni 2026 jadi versi terakhir yang bisa meluluskan Profile S. Lewat 31 Maret 2027, tidak ada produk baru maupun firmware baru yang bisa didaftarkan untuk Profile S.

Biang masalahnya ada di cara login. Profile S mewajibkan username token, skema lama yang menurut ONVIF sudah tidak sejalan dengan praktik keamanan sekarang. Profile T memakai digest authentication, sehingga kata sandi tidak dikirim langsung. Itu tetap perlu dipadukan dengan TLS dan konfigurasi autentikasi yang benar; digest saja tidak mengenkripsi lalu lintas. Dukungan HTTPS juga perlu diperiksa pada perangkat.

Kamera yang sudah terpasang tetap jalan. ONVIF menegaskan produk Profile S yang ada tetap bisa saling bicara. Yang berubah adalah cara belanja:

• Di purchase order, tulis "ONVIF Profile T conformant, terdaftar di onvif.org". Jangan cuma "ONVIF compliant".
• Butuh H.265 lewat ONVIF? Satu-satunya jalan Profile T. Profile S tidak pernah membakukan H.265.
• Setelah Maret 2027, firmware baru tidak bisa diajukan untuk kesesuaian Profile S. Kelanjutan fungsi Profile S pada perangkat yang ada bergantung pada pilihan vendor; tenggat itu tidak otomatis mematikannya.

Mengapa kamera muncul saat dicari, lalu hilang?

Discovery itu mirip memanggil "ada orang?" di satu ruangan lalu menunggu siapa yang menyahut. Perangkat lunak mengirim pesan multicast — satu paket yang dialamatkan ke semua perangkat di jaringan lokal sekaligus — lalu kamera ONVIF membalas dengan alamatnya. Praktis. Namun suaranya tidak tembus ke ruangan sebelah.

Secara bawaan multicast tidak lewat router. Begitu kamera ditaruh di VLAN sendiri (jaringan virtual terpisah di switch yang sama — dan ini memang desain yang benar) sementara server di VLAN lain, discovery kosong. Sebagian managed switch juga menyaring multicast yang dianggap tidak perlu. Installer melihat daftar kosong, lalu menyimpulkan kameranya "tidak ONVIF".

Kegagalan kedua lebih diam-diam. Kamera menjawab dengan alamat yang ia kira miliknya. Kalau router sudah memberi alamat baru, atau kamera ada di balik NAT (router yang menerjemahkan alamat antarjaringan), alamat itu salah. Perangkat lunak tetap menyimpannya. Semua lancar sampai reboot berikutnya.

Gunakan pencarian otomatis sebagai bantuan pemasangan. Tetapkan IP statis atau reservasi DHCP, catat alamat dalam inventaris, lalu tambahkan kamera ke perangkat lunak melalui IP yang diketahui.

Mengapa video macet begitu melewati firewall?

ONVIF membantu mengetahui kemampuan kamera, pilihan aliran, dan alamatnya. RTSP mengatur sesi melalui perintah seperti putar, jeda, dan berhenti. Paket RTP kemudian membawa media videonya.

Banyak klien secara bawaan minta RTP lewat UDP, di sepasang port yang disepakati per aliran. Di satu LAN datar, ini dapat memberi latensi rendah, tetapi keamanan dan kehilangan paket tetap perlu dinilai. Lain cerita kalau jalurnya lewat router, firewall, VPN, atau cloud. Port-nya berubah-ubah, sering diblokir atau dibuang. Paket UDP yang hilang tampil sebagai kotak-kotak abu-abu yang meleber sampai gambar utuh berikutnya datang.

Pilihan lainnya interleaving: video dititipkan di koneksi TCP yang sama dengan perintah RTSP, sesuai RFC 2326 bagian 10.12. Satu port dan satu koneksi menyederhanakan aturan firewall jika koneksi itu diizinkan. Paket yang hilang dikirim ulang, bukan dibiarkan jadi noda. Harganya: delay bertambah kalau jaringannya buruk.

Untuk jalur melalui router atau sistem analitik, uji RTP melalui TCP. UDP dapat dipertimbangkan untuk rekaman dalam jaringan lokal yang sama. Tentukan pengangkutan di klien, misalnya ffprobe -rtsp_transport tcp, lalu ukur hasilnya pada jalur sebenarnya.

Memilih aliran video untuk analitik

Hampir semua kamera mengeluarkan minimal dua aliran. Aliran utama beresolusi penuh, untuk rekaman. Sub-aliran kecil, biasanya 640×360 atau 720p, untuk tampilan grid dan analitik.

Kebutuhan resolusi mengikuti model deteksi. Jika enam puluh aliran 4K H.265 akhirnya diperkecil menjadi lebar 640 piksel, proses dekode dapat membebani CPU tanpa memberi manfaat setara. Uji aliran sekunder dan hitung kebutuhan perangkat keras berdasarkan resolusi yang benar-benar dipakai.

Jebakannya ada di cara klien memilih aliran. ONVIF menandai aliran dengan token profil, nama yang dikarang kamera sendiri. Vendor bisa mengganti nama atau urutan token setelah pembaruan firmware. Integrasi yang menyimpan "token kedua" bisa diam-diam pindah ke aliran utama, atau ke aliran yang sudah tidak ada. Pilih aliran berdasarkan resolusi dan codec, baca ulang daftarnya setiap kamera reboot, dan catat di log aliran mana yang benar-benar dibuka.

Mengapa analitik telat mulai dan jamnya meleset?

Kompresi video mengirim satu gambar utuh — keyframe — lalu serangkaian bingkai yang hanya berisi bagian yang berubah. Klien yang tersambung di tengah-tengah rangkaian itu belum bisa melihat apa-apa sampai keyframe berikutnya lewat.

Kamera dengan mode "smart codec" memperpanjang jarak antar-keyframe demi hemat bandwidth, kadang sampai beberapa detik kalau adegannya diam. Untuk rekaman, tukarannya masuk akal. Untuk analitik, artinya tiap tersambung kembali dibuka dengan beberapa detik buta, dan klip yang diekspor mulai terlambat. Setel aliran analitik ke satu keyframe tiap satu sampai dua detik, dan matikan smart codec di aliran itu saja.

Stempel waktu gagal dengan pola yang mirip. Stempel waktu RTP menyatakan waktu pengambilan dalam domain jam media dengan nilai awal acak, bukan waktu kalender. Laporan pengirim RTCP dapat memasangkannya dengan waktu kalender (RFC 3550). Jam dinding diambil dari jam kamera sendiri. Kamera tanpa sinkronisasi jam dapat melenceng; ukur galatnya dan jangan mengasumsikan laju pergeseran tertentu. Akibatnya ke bukti rekaman sudah kami bahas di jam yang melenceng dan bukti waktu kejadian. Arahkan semua kamera ke server NTP yang sama dengan NVR.

Apa yang harus diuji sebelum kamera dipasang massal?

Uji satu kamera dari tiap tipe sebelum order dikunci — bukan setelah 120 unit terpasang di tiang:

1. Daftar conformance — tipe, profil, dan versi firmware cocok dengan yang akan dikirim supplier.
2. Tambah lewat IP — dari subnet yang berbeda dengan kamera, discovery dimatikan.
3. Pemilihan aliran — klien memilih aliran sekunder berdasarkan resolusi, dan masih memilih yang sama setelah pembaruan firmware.
4. Jalur kirim — ffprobe -rtsp_transport tcp mengembalikan codec dan resolusi yang diharapkan, lewat jalur firewall dan VPN yang sebenarnya.
5. Reconnect — cabut-colok daya kamera, klien harus tersambung lagi tanpa dimulai ulang.
6. Jarak keyframe — dari connect sampai bingkai pertama tampil, di bawah dua detik.
7. Akun — pengguna khusus non-admin dengan digest authentication. Password admin tidak pernah ditaruh di config integrasi.
8. Uji 24 jam — dengan pemantauan umur bingkai, cek yang sama seperti di pemantauan SNMP untuk ratusan kamera CCTV.

Hasil delapan pengujian tersebut membantu menilai kecocokan kamera sebelum pengadaan diperluas. Periksa setiap kegagalan dan biaya penanganannya sebelum menerima produk. Setelah aliran dipilih, lanjutkan ke perhitungan penyimpanan CCTV.