Publicera en kameraström: RTSP och HLS är inte samma kant

Du öppnar en kameraport, riktar en spelare mot den och antar att internetproblemet är löst. Sedan kan en telefon inte spela upp den, en webbläsare kan inte spela upp den, och kamerans administrationssida ligger bara en felstavad sökväg från den publika kanten. Den leveransmodell du valde, RTSP eller HLS, avgör det mesta av detta innan en enda brandväggsregel skrivs. VPN:en levererar bara det privata benet.

VPN:en fixar källvägen, inte tittarens väg

En VPS som är ansluten till kamerans LAN via en tunnel kan nå kameran på dess privata adress, och det är verkligen användbart. Det betyder att kameran inte behöver någon egen inkommande port och att hemroutern förblir stängd. Det säger inte vad en tittare kommer att tala. En skrivbordsspelare, en webbläsare, en telefon och en smart-tv stöder olika protokoll, och var och en har sina egna förväntningar på TLS, autentisering och kodekar.

Här är antagandet som är värt att kasta bort: att publicera skulle innebära att göra källan nåbar. Att publicera innebär faktiskt att ge en definierad publik ett stött sätt att konsumera mediet. En publicerad ström har ett format, en publik och en autentiseringsuppgift; en nåbar kamera har inget av det. Nåbarhet är den del som tunneln löser, och tittarens ingångspunkt är den del du fortfarande måste designa.

RTSP är en förhandling, inte en enda port

RTSP bär sessionskontroll: en klient begär en beskrivning, ställer in ett eller flera mediespår och spelar sedan upp. Transporten för själva mediet förhandlas under den inställningen, och det är därför protokollet inte beskrivs väl av en enda vidarebefordrad TCP-port. Den förhandlingen är den del folk missar när de jämför brandväggsregler.

Beroende på ändpunkterna kan RTP komma på separata UDP-portar eller flätas samman på kontrollanslutningen. En relay som bara vidarebefordrar 554 och antar att resten kommer att fungera brukar ge en session som ansluter, rapporterar ett spår och sedan inte visar något. Kontrollera den transport som din kamera faktiskt förhandlar innan du skriver regler för den. En inspelning på den privata sidan besvarar det på en minut, och att gissa kostar en kväll.

För en liten, känd publik med kompatibla spelare kan en medvetet konfigurerad RTSP-relay vara rätt svar. Begränsa vilken källa den får hämta och kräv autentisering vid relayen. Skriv ner de spelare du testade, för en RTSP-ström som fungerar i VLC kan fortfarande misslyckas i en webbläsare.

HLS är en spellista plus resurser

En HLS-tittare hämtar en spellista och hämtar sedan de mediesegment som spellistan namnger. HLS-specifikationen definierar den resursmodellen, och den viktiga driftdetaljen är att spellistor refererar till andra URL:er. Relativa referenser löses mot spellistans plats, så en proxy som skriver om sökvägar måste skriva om dem konsekvent.

Om kameran redan levererar användbar HLS kan en offentlig frontend vidarebefordra de spelliste- och segmentbegäranden genom tunneln. Håll ögonen på nycklar, omdirigeringar och URL:er som applikationen genererar. Varje absolut URL som pekar på en privat värd går sönder i samma ögonblick som en tittare utanför LAN:et följer den. Relativa sökvägar är de som överlever en proxyomskrivning, så föredra dem där du kontrollerar den genererade utdata.

Om kameran bara talar RTSP måste något konvertera källan till tittarens format. Ompaketering och transkodning är olika jobb: ompaketering bevarar kodeken, medan transkodning kodar om den för kompatibilitet, och bara den andra kostar rejält med CPU. Ingen av dem blir nödvändig bara för att en VPN finns i vägen.

Planera upplänken efter var distributionen sker. Ett privat ingest som matar en offentlig medietjänst beter sig helt annorlunda än varje tittare som drar sin egen ström genom tunneln. Det andra mönstret slutar oftast i en mättad hemanslutning och en kamera som verkar fallera slumpmässigt.

Sätt autentiseringen vid den kant du publicerar

TLS, tittarautentisering och åtkomstloggning hör till den publika ingångspunkten, inte till kameran. Det håller kamerans inloggningsuppgifter åtskilda från strömmens inloggningsuppgifter. Det ger dig också en enda plats att återkalla åtkomst när en publikmedlem lämnar. Att sätta de kontrollerna på kameran innebär i stället att varje publikändring blir en administrativ ändring på en enhet som aldrig borde vara publikt nåbar.

Håll VPN:en och kamerans administrationsbehörigheter åtskilda från publiceringsvägen. En VPS som kan nå kamerans webbgränssnitt för att hämta en ström bör inte också vara maskinen som exponerar det gränssnittet. Publiken bör aldrig få veta kamerans adress.

Verifiera sedan de två ändar som du faktiskt byggde i stället för att anta att kedjan fungerar:

$ 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 lyckad sondering av den privata källan och en lyckad spellistehämtning vid den publika kanten bevisar olika halvor av designen. Testa dem separat. Uppspelning från samma typ av klient som din publik använder är det enda test som täcker hela kedjan.

Det du till slut har är en kedja med ett syfte i varje länk: privat källa, begränsat ingest, vald paketering, auktoriserad tittaringång. Ingen av dessa länkar är valfri, och ingen skapas genom att öppna en port.