Publisere en kamerastrøm: RTSP og HLS er ikke samme kant

Du åpner én kameraport, peker en spiller mot den og antar at internettproblemet er løst. Så kan ikke en telefon spille den av, en nettleser kan ikke spille den av, og kameraets administrasjonsside ligger bare en feilskrevet sti fra den offentlige kanten. Leveringsmodellen du valgte, RTSP eller HLS, avgjør det meste av dette før en eneste brannmurregel er skrevet. VPN-en leverer bare det private benet.

VPN-en fikser kildeveien, ikke seerens vei

En VPS som er koblet til kameraets LAN over en tunnel, kan nå kameraet på den private adressen, og det er virkelig nyttig. Det betyr at kameraet ikke trenger noen egen innkommende port, og at hjemmeruteren forblir lukket. Det forteller deg ikke hva en seer vil snakke. En skrivebordsspiller, en nettleser, en telefon og en smart-TV støtter ulike protokoller, og hver av dem har egne forventninger til TLS, autentisering og kodeker.

Her er antakelsen det er verdt å forkaste: at publisering skulle bety å gjøre kilden tilgjengelig. Publisering betyr faktisk å gi et definert publikum en støttet måte å konsumere mediet på. En publisert strøm har et format, et publikum og en legitimasjon; et tilgjengelig kamera har ingen av delene. Tilgjengelighet er den delen tunnelen løser, og seerens inngangspunkt er den delen du fortsatt må designe.

RTSP er en forhandling, ikke en enkelt port

RTSP bærer sesjonskontroll: en klient ber om en beskrivelse, setter opp ett eller flere mediespor og spiller deretter av. Transporten for selve mediet forhandles under det oppsettet, og derfor beskrives protokollen ikke godt av én videresendt TCP-port. Den forhandlingen er den delen folk overser når de sammenligner brannmurregler.

Avhengig av endepunktene kan RTP ankomme på separate UDP-porter eller være flettet sammen på kontrollforbindelsen. En relay som bare videresender 554 og antar at resten vil fungere, gir ofte en sesjon som kobler til, rapporterer et spor og deretter ikke viser noe. Sjekk transporten kameraet ditt faktisk forhandler før du skriver regler for den. Et opptak på den private siden svarer på det på et minutt, og gjetting koster en kveld.

For et lite, kjent publikum med kompatible spillere kan en bevisst konfigurert RTSP-relay være det riktige svaret. Begrens hvilken kilde den får hente, og krev autentisering ved relayen. Skriv ned spillerne du testet, for en RTSP-strøm som fungerer i VLC kan fortsatt feile i en nettleser.

HLS er en spilleliste pluss ressurser

En HLS-seer henter en spilleliste og henter deretter mediesegmentene som spillelisten navngir. HLS-spesifikasjonen definerer den ressursmodellen, og den viktige driftsdetaljen er at spillelister refererer til andre URL-er. Relative referanser løses mot spillelistens plassering, så en proxy som skriver om stier må skrive dem om konsekvent.

Hvis kameraet allerede leverer brukbar HLS, kan en offentlig frontend videresende de spilleliste- og segmentforespørslene gjennom tunnelen. Hold øye med nøkler, omdirigeringer og URL-er som applikasjonen genererer. Enhver absolutt URL som peker på en privat vert, brytes i det øyeblikket en seer utenfor LAN-et følger den. Relative stier er de som overlever en proxy-omskriving, så foretrekk dem der du kontrollerer den genererte utdataen.

Hvis kameraet bare snakker RTSP, må noe konvertere kilden til seerformatet. Ompakking og transkoding er forskjellige jobber: ompakking bevarer kodeken, mens transkoding koder den om for kompatibilitet, og bare den andre koster seriøs CPU. Ingen av dem blir nødvendig bare fordi en VPN er i veien.

Planlegg opplenken etter hvor distribusjonen skjer. Ett privat ingest som mater en offentlig medietjeneste oppfører seg svært annerledes enn hver seer som drar sin egen strøm gjennom tunnelen. Det andre mønsteret ender vanligvis i en mettet hjemmeforbindelse og et kamera som tilsynelatende feiler tilfeldig.

Sett autentiseringen ved kanten du publiserer

TLS, seerautentisering og tilgangslogging hører til det offentlige inngangspunktet, ikke til kameraet. Det holder legitimasjonen for kameraet atskilt fra legitimasjonen for strømmen. Det gir deg også ett sted å tilbakekalle tilgang når et publikumsmedlem forlater. Å sette de kontrollene på kameraet betyr i stedet at enhver publikumsendring blir en administrativ endring på en enhet som aldri burde vært offentlig tilgjengelig.

Hold VPN-en og kameraets administrasjonstillatelser atskilt fra publiseringsveien. En VPS som kan nå kameraets webgrensesnitt for å hente en strøm, bør ikke også være maskinen som eksponerer det grensesnittet. Publikum bør aldri få vite kameraets adresse.

Verifiser deretter de to endene du faktisk bygde, i stedet for å anta at kjeden fungerer:

$ 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 av den private kilden og en vellykket spillelistehenting ved den offentlige kanten beviser ulike halvdeler av designet. Test dem hver for seg. Avspilling fra samme type klient som publikum ditt bruker, er den eneste testen som dekker hele kjeden.

Det du ender opp med, er en kjede med et formål i hvert ledd: privat kilde, begrenset ingest, valgt pakking, autorisert seerinngang. Ingen av disse leddene er valgfrie, og ingen av dem skapes ved å åpne en port.