Udgive en kamerastream: RTSP og HLS er ikke den samme kant

Du åbner én cameraport, peger en afspiller mod den og antager, at internetproblemet er løst. Så kan en telefon ikke afspille den, en browser kan ikke afspille den, og kameraets administrationsside ligger kun en fejlskrevet sti fra den offentlige kant. Den leveringsmodel, du valgte, RTSP eller HLS, bestemmer det meste af det, før en eneste firewallregel er skrevet. VPN'en leverer kun det private ben.

VPN'en retter kildevejen, ikke seerens vej

En VPS, der er forbundet med kameraets LAN gennem en tunnel, kan nå kameraet på dets private adresse, og det er virkelig nyttigt. Det betyder, at kameraet ikke har brug for nogen egen indgående port, og at hjemmerouteren forbliver lukket. Det fortæller dig ikke, hvad en seer vil tale. En desktopafspiller, en browser, en telefon og et smart-tv understøtter forskellige protokoller, og hver især har egne forventninger til TLS, godkendelse og codecs.

Her er den antagelse, der er værd at kassere: at udgive skulle betyde at gøre kilden tilgængelig. At udgive betyder faktisk at give et defineret publikum en understøttet måde at forbruge mediet på. En udgivet stream har et format, et publikum og en legitimationsoplysning; et tilgængeligt kamera har ingen af delene. Tilgængelighed er den del, tunnelen løser, og seerens indgangspunkt er den del, du stadig skal designe.

RTSP er en forhandling, ikke en enkelt port

RTSP bærer sessionsstyring: en klient beder om en beskrivelse, opsætter et eller flere mediespor og afspiller derefter. Transporten for selve mediet forhandles under den opsætning, og derfor beskrives protokollen ikke godt af én videresendt TCP-port. Den forhandling er den del, folk overser, når de sammenligner firewallregler.

Afhængigt af endepunkterne kan RTP ankomme på separate UDP-porte eller være flettet ind i kontrolforbindelsen. Et relay, der kun videresender 554 og antager, at resten nok skal virke, giver ofte en session, der forbinder, rapporterer et spor og derefter ikke viser noget. Kontrollér den transport, dit kamera faktisk forhandler, før du skriver regler for den. En optagelse på den private side besvarer det på et minut, og gætteri koster en aften.

For et lille, kendt publikum med kompatible afspillere kan et bevidst konfigureret RTSP-relay være det rigtige svar. Begræns, hvilken kilde det må trække, og kræv godkendelse ved relayet. Skriv de afspillere ned, du testede, for en RTSP-stream, der virker i VLC, kan stadig fejle i en browser.

HLS er en playliste plus ressourcer

En HLS-seer henter en playliste og henter derefter de mediesegmenter, som playlisten navngiver. HLS-specifikationen definerer den ressourcemodel, og den vigtige driftsdetalje er, at playlister refererer til andre URL'er. Relative referencer opløses i forhold til playlistens placering, så en proxy, der omskriver stier, skal omskrive dem konsekvent.

Hvis kameraet allerede leverer brugbar HLS, kan en offentlig frontend videresende de playliste- og segmentanmodninger gennem tunnelen. Hold øje med nøgler, omdirigeringer og URL'er, som applikationen genererer. Enhver absolut URL, der peger på en privat vært, brækker i det øjeblik, en seer uden for LAN'et følger den. Relative stier er dem, der overlever en proxyomskrivning, så foretræk dem, hvor du kontrollerer det genererede output.

Hvis kameraet kun taler RTSP, skal noget konvertere kilden til seerens format. Genindpakning og transkodning er forskellige opgaver: genindpakning bevarer codec'en, mens transkodning genkoder den for kompatibilitet, og kun den anden koster seriøs CPU. Ingen af dem bliver nødvendige, blot fordi en VPN er i vejen.

Planlæg uplink ud fra, hvor distributionen sker. Ét privat ingest, der leverer til en offentlig medietjeneste, opfører sig meget anderledes end hver seer, der trækker sin egen stream gennem tunnelen. Det andet mønster ender normalt i en mættet hjemmeforbindelse og et kamera, der tilsyneladende fejler tilfældigt.

Sæt godkendelsen ved den kant, du udgiver

TLS, seergodkendelse og adgangslogning hører til det offentlige indgangspunkt, ikke til kameraet. Det holder legitimationsoplysningerne til kameraet adskilt fra legitimationsoplysningerne til streamen. Det giver dig også ét sted at tilbagekalde adgang, når et medlem af publikum forsvinder. At sætte de kontroller på kameraet betyder i stedet, at enhver publikumsændring bliver en administrativ ændring på en enhed, der aldrig burde være offentligt tilgængelig.

Hold VPN'en og kameraets administrationstilladelser adskilt fra udgivelsesvejen. En VPS, der kan nå kameraets webgrænseflade for at trække en stream, bør ikke også være maskinen, der eksponerer den grænseflade. Publikum bør aldrig lære kameraets adresse.

Bekræft derefter de to ender, du faktisk har bygget, i stedet for at antage, at kæden virker:

$ 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

En vellykket sondering af den private kilde og en vellykket playlistehentning ved den offentlige kant beviser forskellige halvdele af designet. Test dem hver for sig. Afspilning fra den samme slags klient, som dit publikum bruger, er den eneste test, der dækker hele kæden.

Det, du ender med, er en kæde med et formål i hvert led: privat kilde, begrænset ingest, valgt indpakning, autoriseret seerindgang. Ingen af de led er valgfrie, og ingen af dem opstår ved at åbne en port.