Publisere ein kamerastraum: RTSP og HLS er ikkje same kant

Du opnar éin kameraport, peikar ein spelar mot han og tek for gitt at internettproblemet er løyst. Så kan ein telefon ikkje spele han av, ein nettlesar kan ikkje spele han av, og administrasjonssida til kameraet ligg berre ein feilskriven sti frå den offentlege kanten. Leveringsmodellen du valde, RTSP eller HLS, avgjer det meste av dette før ein einaste brannmurregel er skriven. VPN-en leverer berre det private beinet.

VPN-en rettar kjeldevegen, ikkje vegen til sjåaren

Ein VPS som er kopla til LAN-et til kameraet over ein tunnel, kan nå kameraet på den private adressa, og det er verkeleg nyttig. Det betyr at kameraet ikkje treng nokon eigen innkomande port, og at heimerutaren blir verande stengd. Det fortel deg ikkje kva ein sjåar vil snakke. Ein skrivebordsspelar, ein nettlesar, ein telefon og ein smart-TV støttar ulike protokollar, og kvar av dei har eigne forventningar til TLS, autentisering og kodekar.

Her er føresetnaden det er verdt å forkaste: at publisering skulle bety å gjere kjelda tilgjengeleg. Publisering betyr faktisk å gi eit definert publikum ein støtta måte å konsumere mediet på. Ein publisert straum har eit format, eit publikum og ein legitimasjon; eit tilgjengeleg kamera har ingen av delane. Tilgjenge er den delen tunnelen løyser, og inngangspunktet til sjåaren er den delen du framleis må designe.

RTSP er ei forhandling, ikkje ein einaste port

RTSP ber sesjonskontroll: ein klient ber om ei skildring, set opp eitt eller fleire mediespor og spelar deretter av. Transporten for sjølve mediet blir forhandla under det oppsettet, og derfor blir protokollen ikkje godt skildra av éin videresendt TCP-port. Den forhandlinga er den delen folk overser når dei samanliknar brannmurreglar.

Avhengig av endepunkta kan RTP kome på separate UDP-portar eller vere fletta saman på kontrollforbindinga. Ein relay som berre videresender 554 og tek for gitt at resten vil fungere, gir ofte ein sesjon som koplar til, rapporterer eit spor og deretter ikkje viser noko. Sjekk transporten kameraet ditt faktisk forhandlar før du skriv reglar for han. Eit opptak på den private sida svarar på det på eit minutt, og gjetting kostar ein kveld.

For eit lite, kjent publikum med kompatible spelarar kan ein medvite konfigurert RTSP-relay vere det rette svaret. Avgrense kva kjelde han får hente, og krev autentisering ved relayen. Skriv ned spelarane du testa, for ein RTSP-straum som fungerer i VLC kan framleis feile i ein nettlesar.

HLS er ei speleliste pluss ressursar

Ein HLS-sjåar hentar ei speleliste og hentar deretter mediesegmenta som spelelista namngir. HLS-spesifikasjonen definerer den ressursmodellen, og den viktige driftsdetaljen er at spelelister refererer til andre URL-ar. Relative referansar blir løyste mot plasseringa til spelelista, så ein proxy som skriv om stiar må skrive dei om konsekvent.

Dersom kameraet allereie leverer brukbar HLS, kan ein offentleg frontend videresende dei speleliste- og segmentførespurnadene gjennom tunnelen. Hald auge med nøklar, omdirigeringar og URL-ar som applikasjonen genererer. Kvar absolutt URL som peikar på ein privat vert, bryt saman i det augeblikket ein sjåar utanfor LAN-et følgjer han. Relative stiar er dei som overlever ei proxy-omskriving, så føretrekk dei der du kontrollerer den genererte utdataen.

Dersom kameraet berre snakkar RTSP, må noko konvertere kjelda til sjåarformatet. Ompakking og transkoding er forskjellige jobbar: ompakking bevarar kodeken, medan transkoding kodar han om for kompatibilitet, og berre den andre kostar seriøs CPU. Ingen av dei blir nødvendige berre fordi ein VPN er i vegen.

Planlegg opplenka etter kvar distribusjonen skjer. Eitt privat ingest som matar ein offentleg medieteneste, oppfører seg svært annleis enn kvar sjåar som dreg sin eigen straum gjennom tunnelen. Det andre mønsteret endar vanlegvis i ei metta heimeforbinding og eit kamera som tilsynelatande feilar tilfeldig.

Set autentiseringa ved kanten du publiserer

TLS, sjåarautentisering og tilgangslogging høyrer til det offentlege inngangspunktet, ikkje til kameraet. Det held legitimasjonen for kameraet skild frå legitimasjonen for straumen. Det gir deg også eitt stad å trekkje tilbake tilgang når eit publikumsmedlem forlèt. Å setje dei kontrollane på kameraet betyr i staden at kvar publikumsendring blir ei administrativ endring på ei eining som aldri burde vore offentleg tilgjengeleg.

Hald VPN-en og administrasjonstillatingane til kameraet skilde frå publiseringsvegen. Ein VPS som kan nå webgrensesnittet til kameraet for å hente ein straum, bør ikkje også vere maskinen som eksponerer det grensesnittet. Publikum bør aldri få vite adressa til kameraet.

Verifiser deretter dei to endane du faktisk bygde, i staden for å ta for gitt at kjeda 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

Ei vellukka sondering av den private kjelda og ei vellukka spelelistehenting ved den offentlege kanten beviser ulike halvdelar av designet. Test dei kvar for seg. Avspeling frå same type klient som publikumet ditt brukar, er den einaste testen som dekkjer heile kjeda.

Det du endar opp med, er ei kjede med eit føremål i kvart ledd: privat kjelde, avgrensa ingest, vald pakking, autorisert sjåarinngang. Ingen av desse ledda er valfrie, og ingen av dei blir skapte ved å opne ein port.