Kamerastroom publiseer: RTSP en HLS is nie dieselfde rand nie

Jy maak een kamerapoort oop, wys 'n speler daarop en aanvaar die internetprobleem is opgelos. Dan kan 'n selfoon dit nie speel nie, kan 'n blaaier dit nie speel nie, en die kamera se administrasiebladsy is net een verkeerd getikte pad van die publieke rand af. Die afleweringsmodel wat jy gekies het, RTSP of HLS, bepaal die meeste daarvan voordat enige firewall-reël geskryf word. Die VPN verskaf net die private been.

Die VPN maak die bronpad reg, nie die kyker se pad nie

'n VPS wat deur 'n tonnel aan die kamera se LAN gekoppel is, kan die kamera by sy private adres bereik, en dit is werklik nuttig. Dit beteken die kamera het geen eie inkomende poort nodig nie en die huisroeteerder bly toe. Dit sê nie vir jou watter taal 'n kyker sal praat nie. 'n Rekenaarspeler, 'n blaaier, 'n selfoon en 'n slim-TV ondersteun verskillende protokolle, en elkeen het sy eie verwagtinge oor TLS, verifikasie en kodeks.

Hier is die aanname wat die moeite werd is om te laat vaar: publikasie sou beteken om die bron bereikbaar te maak. Publikasie beteken eintlik om aan 'n gedefinieerde gehoor 'n ondersteunde manier te gee om die media te verbruik. 'n Gepubliseerde stroom het 'n formaat, 'n gehoor en 'n geloofsbrief; 'n bereikbare kamera het nie een daarvan nie. Bereikbaarheid is die deel wat die tonnel oplos, en die kyker se ingangspunt is die deel wat jy nog moet ontwerp.

RTSP is 'n onderhandeling, nie 'n enkele poort nie

RTSP dra sessiebeheer: 'n kliënt vra 'n beskrywing, stel een of meer mediabrûe op en speel dan. Die vervoer van die media self word tydens daardie opstelling onderhandel, daarom word die protokol nie goed deur een deurgestuurde TCP-poort beskryf nie. Daardie onderhandeling is die deel wat mense mis wanneer hulle firewall-reëls vergelyk.

Afhangend van die eindpunte kan RTP op afsonderlike UDP-poorte aankom of op die beheerverbinding ingevleg word. 'n Herleier wat net 554 deurstuur en aanvaar die res sal werk, lewer gewoonlik 'n sessie wat verbind, 'n spoor rapporteer en dan niks wys nie. Kontroleer die vervoer wat jou kamera werklik onderhandel voordat jy reëls daarvoor skryf. 'n Opname aan die private kant beantwoord dit in 'n minuut, en raai kos 'n aand.

Vir 'n klein, bekende gehoor met versoenbare spelers kan 'n doelbewus opgestelde RTSP-herleier die regte antwoord wees. Beperk watter bron dit mag trek en vereis verifikasie by die herleier. Skryf die spelers neer wat jy getoets het, want 'n RTSP-stroom wat in VLC werk, kan steeds in 'n blaaier misluk.

HLS is 'n snitlys plus hulpbronne

'n HLS-kyker haal 'n snitlys en haal dan die mediasegmente wat daardie lys noem. Die HLS-spesifikasie definieer daardie hulpbronmodel, en die belangrike operasionele detail is dat snitlyste na ander URL's verwys. Relatiewe verwysings word teen die lys se ligging opgelos, so 'n proxy wat paaie herskryf, moet dit konsekwent herskryf.

As die kamera reeds bruikbare HLS lewer, kan 'n publieke frontend daardie snitlys- en segmentversoeke deur die tonnel stuur. Let op sleutels, herleidings en URL's wat die toepassing genereer. Enige absolute URL wat na 'n private gasheer wys, breek die oomblik wanneer 'n kyker buite die LAN dit volg. Relatiewe paaie is diegene wat 'n herskrywing deur die proxy oorleef, so verkies hulle oral waar jy die gegenereerde uitset beheer.

As die kamera net RTSP praat, moet iets die bron na die kyker se formaat omskakel. Herverpakking en transkodering is verskillende take: herverpakking bewaar die kodek, terwyl transkodering dit vir versoenbaarheid herkodeer, en net die tweede kos ernstige CPU. Nie een word nodig net omdat daar 'n VPN op die pad is nie.

Beplan die opvoerlyn rondom waar die verspreiding plaasvind. Een private invoer wat 'n publieke mediadiens voed, gedra hom heel anders as elke kyker wat sy eie stroom deur die tonnel trek. Die tweede patroon eindig gewoonlik in 'n versadigde huisverbinding en 'n kamera wat skynbaar lukraak misluk.

Plaas verifikasie op die rand wat jy publiseer

TLS, kykerverifikasie en toegangslogtoring hoort by die publieke ingangspunt, nie by die kamera nie. Dit hou die kamera se geloofsbriewe apart van die stroom se geloofsbriewe. Dit gee jou ook een plek om toegang te herroep wanneer 'n lid van die gehoor weggaan. Om daardie beheermaatreëls op die kamera te plaas, beteken eerder dat elke gehoorverandering 'n administratiewe verandering word op 'n toestel wat nooit publiek bereikbaar behoort te wees nie.

Hou die VPN en die kamera se administrasieregte apart van die publikasiepad. 'n VPS wat die kamera se webkoppelvlak kan bereik om 'n stroom te trek, behoort nie ook die masjien te wees wat daardie koppelvlak blootstel nie. Die gehoor behoort nooit die kamera se adres te leer nie.

Verifieer dan die twee punte wat jy werklik gebou het in plaas daarvan om aan te neem die ketting werk:

$ 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

'n Suksesvolle ondersoek van die private bron en 'n suksesvolle snitlys-ophaal by die publieke rand bewys verskillende helftes van die ontwerp. Toets hulle afsonderlik. Terugspeel vanaf dieselfde soort kliënt wat jou gehoor gebruik, is die enigste toets wat die hele ketting dek.

Wat jy uiteindelik het, is 'n ketting met 'n doel by elke skakel: private bron, beperkte invoer, gekose verpakking, gemagtigde kyker-ingang. Nie een van daardie skakels is opsioneel nie, en nie een word geskep deur 'n poort oop te maak nie.