Kamerastriimin julkaiseminen: RTSP ja HLS eivät ole sama reuna

Avaat yhden kameraportin, osoitat soittimen siihen ja oletat, että internetongelma on ratkaistu. Sitten puhelin ei voi toistaa sitä, selain ei voi toistaa sitä, ja kameran hallintasivu on vain yhden väärin kirjoitetun polun päässä julkisesta reunasta. Valitsemasi toimitustapa, RTSP tai HLS, ratkaisee suurimman osan tästä ennen kuin yhtään palomuurisääntöä kirjoitetaan. VPN tarjoaa vain yksityisen osuuden.

VPN korjaa lähdepolun, ei katsojan polkua

VPS, joka on liitetty kameran lähiverkkoon tunnelin kautta, voi tavoittaa kameran sen yksityisestä osoitteesta, ja se on todella hyödyllistä. Se tarkoittaa, että kamera ei tarvitse omaa saapuvaa porttia ja kotireititin pysyy suljettuna. Se ei kerro, mitä katsoja tulee puhumaan. Työpöytäsoitin, selain, puhelin ja älytelevisio tukevat eri protokollia, ja jokaisella on omat odotuksensa TLS:stä, todennuksesta ja koodekeista.

Tässä on oletus, joka kannattaa hylätä: julkaiseminen tarkoittaisi lähteen saattamista tavoitettavaksi. Julkaiseminen tarkoittaa itse asiassa sitä, että määritellylle yleisölle annetaan tuettu tapa kuluttaa mediaa. Julkaistulla striimillä on muoto, yleisö ja tunniste; tavoitettavalla kameralla ei ole mitään näistä. Tavoitettavuus on se osa, jonka tunneli ratkaisee, ja katsojan sisääntulopiste on se osa, joka sinun on vielä suunniteltava.

RTSP on neuvottelu, ei yksittäinen portti

RTSP kuljettaa istunnon ohjausta: asiakas pyytää kuvauksen, asettaa yhden tai useamman mediauran ja toistaa sitten. Itse median kuljetus neuvotellaan tuon asetuksen aikana, minkä vuoksi protokollaa ei kuvata hyvin yhdellä välitetyllä TCP-portilla. Tuo neuvottelu on se osa, joka ihmisiltä jää huomaamatta, kun he vertailevat palomuurisääntöjä.

Päätepisteistä riippuen RTP voi saapua erillisille UDP-porteille tai limittyä ohjausyhteyteen. Välityspalvelin, joka välittää vain portin 554 ja olettaa lopun toimivan, tuottaa usein istunnon, joka yhdistää, ilmoittaa uran ja ei sitten näytä mitään. Tarkista kuljetus, josta kamerasi todella neuvottelee, ennen kuin kirjoitat sille sääntöjä. Kaappaus yksityisellä puolella vastaa siihen minuutissa, ja arvaaminen maksaa illan.

Pienelle, tunnetulle yleisölle, jolla on yhteensopivat soittimet, tarkoituksella määritetty RTSP-välitys voi olla oikea vastaus. Rajoita, mistä lähteestä se saa noutaa, ja vaadi todennus välityksessä. Kirjoita muistiin testaamasi soittimet, sillä RTSP-striimi, joka toimii VLC:ssä, voi silti epäonnistua selaimessa.

HLS on soittolista ja resurssit

HLS-katsoja noutaa soittolistan ja noutaa sitten ne mediasegmentit, jotka soittolista nimeää. HLS-määritys määrittelee tuon resurssimallin, ja tärkeä operatiivinen yksityiskohta on, että soittolistat viittaavat muihin URL-osoitteisiin. Suhteelliset viittaukset ratkaistaan soittolistan sijaintia vasten, joten polut uudelleenkirjoittavan välityspalvelimen on kirjoitettava ne johdonmukaisesti uudelleen.

Jos kamera tarjoaa jo käyttökelpoista HLS:ää, julkinen frontend voi välittää nuo soittolista- ja segmenttipyynnöt tunnelin läpi. Varo avaimia, uudelleenohjauksia ja sovelluksen tuottamia URL-osoitteita. Mikä tahansa absoluuttinen URL, joka osoittaa yksityiseen isäntään, hajoaa sillä hetkellä, kun lähiverkon ulkopuolinen katsoja seuraa sitä. Suhteelliset polut ovat niitä, jotka selviävät välityspalvelimen uudelleenkirjoituksesta, joten suosi niitä kaikkialla, missä hallitset tuotettua tulostetta.

Jos kamera puhuu vain RTSP:tä, jonkin on muunnettava lähde katsojan muotoon. Uudelleenpaketointi ja transkoodaus ovat eri töitä: uudelleenpaketointi säilyttää koodekin, kun taas transkoodaus koodaa sen uudelleen yhteensopivuuden vuoksi, ja vain jälkimmäinen maksaa kunnolla suoritintehoa. Kumpikaan ei tule tarpeelliseksi pelkästään siksi, että VPN on polulla.

Suunnittele ylälinkki sen mukaan, missä jakelu tapahtuu. Yksi yksityinen syöte, joka ruokkii julkista mediipalvelua, käyttäytyy hyvin eri tavalla kuin jokainen katsoja, joka vetää oman striiminsä tunnelin läpi. Jälkimmäinen malli päättyy yleensä kyllästyneeseen kotiyhteyteen ja kameraan, joka näyttää epäonnistuvan satunnaisesti.

Sijoita todennus siihen reunaan, jonka julkaiset

TLS, katsojien todennus ja käyttölokitus kuuluvat julkiseen sisääntulopisteeseen, eivät kameraan. Se pitää kameran tunnistetiedot erillään striimin tunnistetiedoista. Se antaa sinulle myös yhden paikan peruuttaa käyttöoikeus, kun yleisön jäsen lähtee. Jos nuo hallinnat laitetaan kameraan, jokaisesta yleisömuutoksesta tulee hallinnollinen muutos laitteeseen, jonka ei pitäisi koskaan olla julkisesti tavoitettavissa.

Pidä VPN ja kameran hallintaoikeudet erillään julkaisupolusta. VPS, joka voi tavoittaa kameran verkkokäyttöliittymän striimin noutamiseksi, ei saisi olla myös kone, joka altistaa tuon käyttöliittymän. Yleisön ei pitäisi koskaan saada tietää kameran osoitetta.

Vahvista sitten ne kaksi päätä, jotka todella rakensit, sen sijaan että olettaisit ketjun toimivan:

$ 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

Yksityisen lähteen onnistunut luotaus ja onnistunut soittolistan nouto julkisella reunalla todistavat suunnittelun eri puolet. Testaa ne erikseen. Toisto samanlaisesta asiakkaasta, jota yleisösi käyttää, on ainoa testi, joka kattaa koko ketjun.

Lopputuloksena on ketju, jossa jokaisella lenkillä on tarkoitus: yksityinen lähde, rajoitettu syöte, valittu paketointi, valtuutettu katsojan sisääntulo. Mikään noista lenkeistä ei ole valinnainen, eikä mikään synny portin avaamalla.