Een camerastream publiceren: RTSP en HLS zijn niet dezelfde rand

U stelt één camerapoort beschikbaar, wijst er een speler op en neemt aan dat het internetprobleem is opgelost. Dan kan een telefoon hem niet afspelen, kan een browser hem niet afspelen, en staat de beheerpagina van de camera op één verkeerd getypt pad van de publieke rand. Het leveringsmodel dat u hebt gekozen, RTSP of HLS, bepaalt het grootste deel daarvan voordat er ook maar één firewallregel is geschreven. De VPN levert alleen het private been.

De VPN repareert het bronpad, niet het kijkerspad

Een VPS die via een tunnel met het cameranetwerk is verbonden, kan de camera op haar private adres bereiken, en dat is echt nuttig. Het betekent dat de camera geen eigen inkomende poort nodig heeft en dat de thuisrouter dicht blijft. Het vertelt u niet welke taal een kijker spreekt. Een desktopspeler, een browser, een telefoon en een smart-tv ondersteunen verschillende protocollen, en elk heeft eigen verwachtingen over TLS, authenticatie en codecs.

Hier is de aanname die u kunt laten vallen: publiceren zou betekenen dat de bron bereikbaar wordt. Publiceren betekent in werkelijkheid dat u een afgebakend publiek een ondersteunde manier geeft om de media te consumeren. Een gepubliceerde stream heeft een formaat, een publiek en een credential; een bereikbare camera heeft geen van die drie. Bereikbaarheid is het deel dat de tunnel oplost, en het toegangspunt voor de kijker is het deel dat u nog moet ontwerpen.

RTSP is een onderhandeling, geen enkele poort

RTSP draagt sessiebeheer: een client vraagt om een beschrijving, zet een of meer mediasporen op en speelt dan af. Het transport voor de media zelf wordt tijdens die opzet onderhandeld, en daarom is het protocol niet goed te beschrijven met één doorgestuurde TCP-poort. Die onderhandeling is het deel dat mensen missen wanneer ze firewallregels vergelijken.

Afhankelijk van de eindpunten kan RTP op afzonderlijke UDP-poorten aankomen of op de besturingsverbinding worden verweven. Een relay die alleen 554 doorstuurt en aanneemt dat de rest wel werkt, levert meestal een sessie op die verbindt, een spoor meldt en dan niets toont. Controleer het transport dat uw camera werkelijk onderhandelt voordat u er regels voor schrijft. Een opname aan de private kant beantwoordt dat in een minuut, en gokken kost een avond.

Voor een klein, bekend publiek met compatibele spelers kan een bewust geconfigureerde RTSP-relay het juiste antwoord zijn. Beperk welke bron hij mag trekken en eis authenticatie bij de relay. Schrijf de spelers op die u hebt getest, want een RTSP-stream die in VLC werkt, kan in een browser alsnog falen.

HLS is een playlist plus bronnen

Een HLS-kijker haalt een playlist op en haalt vervolgens de mediasegmenten op die die playlist noemt. De HLS-specificatie definieert dat bronnenmodel, en het belangrijke operationele detail is dat playlists naar andere URL's verwijzen. Relatieve verwijzingen worden opgelost tegen de locatie van de playlist, dus een proxy die paden herschrijft, moet ze consistent herschrijven.

Als de camera al bruikbare HLS levert, kan een publieke frontend die playlist- en segmentverzoeken via de tunnel doorgeven. Let op sleutels, redirects en URL's die de applicatie genereert. Elke absolute URL die naar een private host wijst, breekt op het moment dat een kijker buiten het netwerk hem volgt. Relatieve paden zijn degene die een herschrijving door de proxy overleven, dus geef ze de voorkeur waar u de gegenereerde uitvoer beheert.

Spreekt de camera alleen RTSP, dan moet iets de bron omzetten naar het kijkersformaat. Herverpakken en transcoderen zijn verschillende taken: herverpakken behoudt de codec, terwijl transcoderen hem voor compatibiliteit opnieuw codeert, en alleen de tweede kost serieuze CPU. Geen van beide wordt nodig alleen omdat er een VPN in het pad zit.

Plan de uplink rond de plek waar de verspreiding gebeurt. Eén private ingest die een publieke mediadienst voedt, gedraagt zich heel anders dan elke kijker die zijn eigen stream door de tunnel trekt. Het tweede patroon eindigt meestal in een verzadigde thuisverbinding en een camera die willekeurig lijkt te falen.

Zet de authenticatie op de rand die u publiceert

TLS, kijkersauthenticatie en toegangslogging horen bij het publieke toegangspunt, niet bij de camera. Dat houdt de inloggegevens voor de camera gescheiden van de inloggegevens voor de stream. Het geeft u ook één plek om toegang in te trekken wanneer een lid van het publiek vertrekt. Die controles op de camera zetten betekent in plaats daarvan dat elke publiekswijziging een beheerswijziging wordt op een apparaat dat nooit publiek bereikbaar zou moeten zijn.

Houd de VPN en de beheerrechten van de camera gescheiden van het publicatiepad. Een VPS die de webinterface van de camera kan bereiken om een stream te trekken, zou niet ook de machine moeten zijn die die interface blootstelt. Het publiek zou het adres van de camera nooit mogen leren.

Controleer dan de twee uiteinden die u werkelijk hebt gebouwd in plaats van aan te nemen dat de keten werkt:

$ 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

Een geslaagde test van de private bron en een geslaagde playlist-ophaling aan de publieke rand bewijzen verschillende helften van het ontwerp. Test ze apart. Afspelen vanaf hetzelfde soort client dat uw publiek gebruikt, is de enige test die de hele keten dekt.

Wat u uiteindelijk krijgt, is een keten met een doel bij elke schakel: private bron, beperkte ingest, gekozen verpakking, geautoriseerde toegang voor kijkers. Geen van die schakels is optioneel, en geen enkele ontstaat door een poort te openen.