Publikigi kameraan fluon: RTSP kaj HLS ne estas la sama rando

Vi malfermas unu pordon de la kamerao, direktas ludilon al ĝi kaj supozas, ke la interreta problemo estas solvita. Poste telefonoj ne povas ludi ĝin, retumilo ne povas ludi ĝin, kaj la administra paĝo de la kamerao troviĝas nur unu mistajpitan vojon for de la publika rando. La livera modelo, kiun vi elektis, RTSP aŭ HLS, decidas la plejmulton de tio antaŭ ol iu ajn fajromura regulo estas skribita. La VPN nur liveras la privatan parton.

La VPN riparas la fontan vojon, ne la vojon de la spektanto

VPS ligita al la loka reto de la kamerao per tunelo povas atingi la kameraon ĉe ĝia privata adreso, kaj tio vere utilas. Ĝi signifas, ke la kamerao ne bezonas propran envenan pordon kaj ke la hejma enkursigilo restas fermita. Ĝi ne diras al vi, kiun lingvon parolos spektanto. Labortabla ludilo, retumilo, telefono kaj inteligenta televido subtenas malsamajn protokolojn, kaj ĉiu havas proprajn atendojn pri TLS, aŭtentikigo kaj kodigiloj.

Jen la supozo, kiun indas forlasi: publikigi signifus igi la fonton atingebla. Publikigi efektive signifas doni al difinita publiko subtenatan manieron konsumi la aŭdovidaĵon. Publikigita fluo havas formaton, publikon kaj akreditaĵon; atingebla kamerao havas neniun el tiuj. Atingebleco estas la parto, kiun solvas la tunelo, kaj la enirpunkto de la spektanto estas la parto, kiun vi ankoraŭ devas desegni.

RTSP estas intertraktado, ne unu pordo

RTSP portas sesian regadon: kliento petas priskribon, agordas unu aŭ plurajn aŭdovidajn trakojn kaj poste ludas. La transporto de la aŭdovidaĵo mem estas interkonsentata dum tiu agordo, tial la protokolo ne estas bone priskribata per unu plusendita TCP-pordo. Tiu intertraktado estas la parto, kiun homoj maltrafas kiam ili komparas fajromurajn regulojn.

Laŭ la finpunktoj, RTP povas alveni sur apartaj UDP-pordoj aŭ esti interplektita en la rega konekto. Relajso, kiu plusendas nur 554 kaj supozas, ke la resto funkcios, kutime produktas sesion, kiu konektiĝas, raportas trakon kaj poste montras nenion. Kontrolu la transporton, pri kiu via kamerao efektive interkonsentas, antaŭ ol skribi regulojn por ĝi. Kaptaĵo ĉe la privata flanko respondas tion en unu minuto, kaj diveni kostas vesperon.

Por malgranda, konata publiko kun kongruaj ludiloj, intence agordita RTSP-relajso povas esti la ĝusta respondo. Limigu, el kiu fonto ĝi rajtas tiri, kaj postulu aŭtentikigon ĉe la relajso. Notu la ludilojn, kiujn vi testis, ĉar RTSP-fluo, kiu funkcias en VLC, ankoraŭ povas malsukcesi en retumilo.

HLS estas ludlisto plus rimedoj

HLS-spektanto prenas ludliston, poste prenas la aŭdovidajn segmentojn, kiujn tiu listo nomas. La HLS-specifikaĵo difinas tiun rimedmodelon, kaj la grava operacia detalo estas, ke ludlistoj referencas aliajn URL-ojn. Relativaj referencoj solviĝas rilate al la loko de la ludlisto, do prokura servilo, kiu reskribas vojojn, devas reskribi ilin konsekvence.

Se la kamerao jam servas uzeblan HLS, publika fasado povas plusendi tiujn ludlistajn kaj segmentajn petojn tra la tunelo. Atentu ŝlosilojn, alidirektigojn kaj URL-ojn, kiujn la aplikaĵo generas. Ĉiu absoluta URL, kiu montras al privata gastiganto, rompiĝas en la momento, kiam spektanto ekster la loka reto sekvas ĝin. Relativaj vojoj estas tiuj, kiuj postvivas reskribon fare de la prokura servilo, do preferu ilin ĉie, kie vi kontrolas la generitan eligon.

Se la kamerao parolas nur RTSP, io devas konverti la fonton al la formato de la spektanto. Reenpakado kaj transkodado estas malsamaj taskoj: reenpakado konservas la kodigilon, dum transkodado rekodas ĝin por kongrueco, kaj nur la dua kostas seriozan CPU. Neniu el ili fariĝas necesa nur ĉar VPN estas sur la vojo.

Planu la suprenligon laŭ tio, kie okazas la disdonado. Unu privata enigo, kiu nutras publikan aŭdovidan servon, kondutas tute alie ol ĉiu spektanto, kiu tiras sian propran fluon tra la tunelo. La dua ŝablono kutime finiĝas per saturita hejma konekto kaj kamerao, kiu ŝajne hazarde paneas.

Metu aŭtentikigon ĉe la rando, kiun vi publikigas

TLS, aŭtentikigo de spektantoj kaj protokolado de aliro apartenas al la publika enirpunkto, ne al la kamerao. Tio tenas la akreditaĵojn de la kamerao aparte de la akreditaĵoj de la fluo. Ĝi ankaŭ donas al vi unu lokon por revoki aliron, kiam membro de la publiko foriras. Meti tiujn regilojn sur la kameraon anstataŭe signifas, ke ĉiu publika ŝanĝo fariĝas administra ŝanĝo sur aparato, kiu neniam devus esti publike atingebla.

Tenu la VPN kaj la administrajn permesojn de la kamerao aparte de la publikiga vojo. VPS, kiu povas atingi la retinterfacon de la kamerao por tiri fluon, ne devus ankaŭ esti la maŝino, kiu elmetas tiun interfacon. La publiko neniam devus ekscii la adreson de la kamerao.

Poste kontrolu la du finojn, kiujn vi efektive konstruis, anstataŭ supozi, ke la ĉeno funkcias:

$ 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

Sukcesa sondado de la privata fonto kaj sukcesa preno de la ludlisto ĉe la publika rando pruvas malsamajn duonojn de la desegno. Testu ilin aparte. Ludado el la sama speco de kliento, kiun uzas via publiko, estas la sola testo, kiu kovras la tutan ĉenon.

Tio, kion vi finfine havas, estas ĉeno kun celo ĉe ĉiu ligilo: privata fonto, limigita enigo, elektita pakaĵo, rajtigita eniro de spektanto. Neniu el tiuj ligiloj estas laŭvola, kaj neniu kreiĝas per malfermo de pordo.