Publicar un flux de càmera: RTSP i HLS no són la mateixa vora

Obriu un port de la càmera, hi apunteu un reproductor i suposeu que el problema d'internet està resolt. Després un telèfon no el pot reproduir, un navegador no el pot reproduir, i la pàgina d'administració de la càmera és a només un camí mal escrit de la vora pública. El model de lliurament que heu triat, RTSP o HLS, decideix la major part d'això abans que s'escrigui cap regla de tallafoc. La VPN només aporta el tram privat.

La VPN arregla el camí de l'origen, no el de l'espectador

Un VPS connectat a la LAN de la càmera mitjançant un túnel pot arribar a la càmera a la seva adreça privada, i això és realment útil. Significa que la càmera no necessita cap port d'entrada propi i que l'encaminador de casa roman tancat. No us diu quina llengua parlarà un espectador. Un reproductor d'escriptori, un navegador, un telèfon i un televisor intel·ligent admeten protocols diferents, i cadascun té les seves pròpies expectatives sobre TLS, autenticació i còdecs.

Vet aquí la suposició que val la pena descartar: publicar significaria fer l'origen accessible. Publicar en realitat significa donar a un públic definit una manera admesa de consumir el mitjà. Un flux publicat té format, públic i credencial; una càmera accessible no té res d'això. L'accessibilitat és la part que resol el túnel, i el punt d'entrada de l'espectador és la part que encara heu de dissenyar.

RTSP és una negociació, no un sol port

RTSP porta el control de sessió: un client demana una descripció, configura una o més pistes de mitjans i després reprodueix. El transport dels mitjans mateixos es negocia durant aquesta configuració, per això el protocol no queda ben descrit per un únic port TCP reenviat. Aquesta negociació és la part que la gent passa per alt quan compara regles de tallafoc.

Segons els extrems, RTP pot arribar per ports UDP separats o entrellaçar-se a la connexió de control. Un relé que només reenvia 554 i suposa que la resta funcionarà sol produir una sessió que es connecta, informa d'una pista i després no mostra res. Comproveu el transport que la vostra càmera negocia realment abans d'escriure regles per a ell. Una captura al costat privat ho respon en un minut, i endevinar-ho costa un vespre.

Per a un públic petit i conegut amb reproductors compatibles, un relé RTSP configurat deliberadament pot ser la resposta correcta. Limiteu de quin origen pot estirar i exigiu autenticació al relé. Anoteu els reproductors que heu provat, perquè un flux RTSP que funciona al VLC encara pot fallar en un navegador.

HLS és una llista de reproducció més recursos

Un espectador d'HLS obté una llista de reproducció i després obté els segments de mitjans que aquesta llista anomena. L'especificació HLS defineix aquest model de recursos, i el detall operatiu important és que les llistes fan referència a altres URL. Les referències relatives es resolen respecte de la ubicació de la llista, així que un proxy que reescrigui camins els ha de reescriure de manera coherent.

Si la càmera ja serveix HLS utilitzable, un frontal públic pot retransmetre aquestes sol·licituds de llista i de segments a través del túnel. Vigileu les claus, les redireccions i els URL que genera l'aplicació. Qualsevol URL absolut que apunti a un amfitrió privat es trenca en el moment que un espectador fora de la LAN el segueix. Els camins relatius són els que sobreviuen a una reescriptura del proxy, així que preferiu-los allà on controleu la sortida generada.

Si la càmera només parla RTSP, alguna cosa ha de convertir l'origen al format de l'espectador. El reempaquetatge i la transcodificació són feines diferents: el reempaquetatge conserva el còdec, mentre que la transcodificació el recodifica per compatibilitat, i només la segona costa CPU de debò. Cap de les dues no es fa necessària només perquè hi hagi una VPN al camí.

Planifiqueu l'enllaç ascendent segons on es produeixi la distribució. Una única ingesta privada que alimenta un servei de mitjans públic es comporta molt diferent de cada espectador que estira el seu propi flux pel túnel. El segon patró sol acabar en una connexió domèstica saturada i una càmera que sembla fallar a l'atzar.

Poseu l'autenticació a la vora que publiqueu

TLS, l'autenticació d'espectadors i el registre d'accés pertanyen al punt d'entrada públic, no a la càmera. Això manté les credencials de la càmera separades de les credencials del flux. També us dona un lloc únic on revocar l'accés quan un membre del públic se'n va. Posar aquests controls a la càmera significa, en canvi, que cada canvi de públic es converteix en un canvi administratiu en un dispositiu que mai no hauria de ser accessible públicament.

Manteniu la VPN i els permisos d'administració de la càmera separats del camí de publicació. Un VPS que pot arribar a la interfície web de la càmera per estirar un flux no hauria de ser també la màquina que exposa aquesta interfície. El públic no hauria de saber mai l'adreça de la càmera.

Després verifiqueu els dos extrems que heu construït realment en lloc de suposar que la cadena funciona:

$ 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

Una sonda correcta de l'origen privat i una obtenció correcta de la llista a la vora pública demostren meitats diferents del disseny. Prova-les per separat. La reproducció des del mateix tipus de client que usa el vostre públic és l'única prova que cobreix tota la cadena.

El que acabeu tenint és una cadena amb un propòsit a cada baula: origen privat, ingesta restringida, empaquetatge escollit, entrada d'espectador autoritzada. Cap d'aquestes baules no és opcional, i cap no es crea obrint un port.