კამერის ნაკადის გამოქვეყნება: RTSP და HLS ერთი კიდე არ არის

თქვენ ხსნით კამერის ერთ პორტს, მიმართავთ მას პლეერს და ვარაუდობთ, რომ ინტერნეტის პრობლემა მოგვარებულია. შემდეგ ტელეფონს არ შეუძლია მისი დაკვრა, ბრაუზერს არ შეუძლია მისი დაკვრა, ხოლო კამერის ადმინისტრირების გვერდი საჯარო კიდიდან მხოლოდ ერთი არასწორად აკრეფილი ბილიკითაა დაშორებული. თქვენ მიერ არჩეული მიწოდების მოდელი, RTSP თუ HLS, ამის უმეტეს ნაწილს წყვეტს სანამ რომელიმე firewall წესი დაიწერება. VPN მხოლოდ კერძო მონაკვეთს იძლევა.

VPN ასწორებს წყაროს გზას და არა მაყურებლის გზას

VPS, რომელიც გვირაბით კამერის ლოკალურ ქსელს უკავშირდება, შეუძლია კამერამდე მივიდეს მისი კერძო მისამართით, და ეს ნამდვილად სასარგებლოა. ეს ნიშნავს, რომ კამერას არ სჭირდება საკუთარი შემავალი პორტი და სახლის როუტერი დახურული რჩება. ეს არ გეუბნებათ, რა ენაზე ილაპარაკებს მაყურებელი. დესკტოპის პლეერი, ბრაუზერი, ტელეფონი და ჭკვიანი ტელევიზორი სხვადასხვა პროტოკოლს მხარს უჭერენ და თითოეულს აქვს საკუთარი მოლოდინები TLS-ის, ავთენტიფიკაციისა და კოდეკების მიმართ.

აი ვარაუდი, რომლის გადაგდებაც ღირს: გამოქვეყნება თითქოს წყაროს ხელმისაწვდომს ხდის. გამოქვეყნება სინამდვილეში ნიშნავს, რომ განსაზღვრულ აუდიტორიას მიეცეს მედიის მოხმარების მხარდაჭერილი გზა. გამოქვეყნებულ ნაკადს აქვს ფორმატი, აუდიტორია და წვდომის მონაცემები; ხელმისაწვდომ კამერას არც ერთი არ აქვს. ხელმისაწვდომობა არის ის ნაწილი, რომელსაც გვირაბი წყვეტს, ხოლო მაყურებლის შესვლის წერტილი არის ის ნაწილი, რომელიც ჯერ კიდევ უნდა დააპროექტოთ.

RTSP მოლაპარაკებაა და არა ერთი პორტი

RTSP ატარებს სესიის მართვას: კლიენტი ითხოვს აღწერას, აყენებს ერთ ან რამდენიმე მედია ბილიკს და შემდეგ უკრავს. თავად მედიის ტრანსპორტი ამ დაყენების დროს მუშავდება, ამიტომ პროტოკოლი კარგად არ აღიწერება ერთი გადამისამართებული TCP პორტით. ეს მოლაპარაკება არის ის ნაწილი, რომელსაც ადამიანები გამოტოვებენ firewall წესების შედარებისას.

ბოლო წერტილებიდან გამომდინარე, RTP შეიძლება მოვიდეს ცალკე UDP პორტებზე ან იყოს ჩაქსოვილი მართვის კავშირში. რელე, რომელიც გადასცემს მხოლოდ 554-ს და ვარაუდობს, რომ დანარჩენი იმუშავებს, ჩვეულებრივ ქმნის სესიას, რომელიც უკავშირდება, აცნობს ბილიკს და შემდეგ არაფერს აჩვენებს. სანამ წესებს დაწერთ, შეამოწმეთ, რომელ ტრანსპორტზე მოლაპარაკებას აწარმოებს თქვენი კამერა. კერძო მხარეს ჩანაწერი ამას ერთ წუთში პასუხობს, ხოლო გამოცნობა საღამო ღირს.

პატარა, ცნობილი აუდიტორიისთვის თავსებადი პლეერებით, განზრახ კონფიგურირებული RTSP რელე შეიძლება იყოს სწორი პასუხი. შეზღუდეთ, რომელი წყაროდან შეიძლება ჩამოტანა და მოითხოვეთ ავთენტიფიკაცია რელეზე. ჩაწერეთ პლეერები, რომლებიც გამოსცადეთ, რადგან VLC-ში მომუშავე RTSP ნაკადი ბრაუზერში მაინც შეიძლება ჩავარდეს.

HLS არის დაკვრის სია პლუს რესურსები

HLS მაყურებელი იღებს დაკვრის სიას, შემდეგ იღებს იმ მედია სეგმენტებს, რომლებსაც ეს სია ასახელებს. HLS სპეციფიკაცია განსაზღვრავს ამ რესურსების მოდელს და მნიშვნელოვანი ოპერაციული დეტალია, რომ დაკვრის სიები სხვა URL-ებზე მიუთითებენ. ფარდობითი მითითებები იხსნება სიის მდებარეობის მიმართ, ამიტომ ბილიკების გადამწერ პროქსის ისინი თანმიმდევრულად უნდა გადაწეროს.

თუ კამერა უკვე ემსახურება გამოსადეგ HLS-ს, საჯარო ფრონტენდს შეუძლია ამ სიისა და სეგმენტის მოთხოვნების გვირაბის გავლით გადაცემა. დააკვირდით გასაღებებს, გადამისამართებებს და URL-ებს, რომლებსაც აპლიკაცია ქმნის. ნებისმიერი აბსოლუტური URL, რომელიც კერძო ჰოსტზე მიუთითებს, იმ წუთას იშლება, როცა ლოკალური ქსელის გარეთ მყოფი მაყურებელი მას მიჰყვება. ფარდობითი ბილიკები არიან ისინი, რომლებიც გადაურჩება პროქსის გადაწერას, ამიტომ უპირატესობა მიეცით მათ ყველგან, სადაც აკონტროლებთ გენერირებულ გამოსავალს.

თუ კამერა მხოლოდ RTSP-ს ლაპარაკობს, რაღაცამ უნდა გადააქციოს წყარო მაყურებლის ფორმატად. ხელახალი შეფუთვა და ტრანსკოდირება სხვადასხვა სამუშაოა: ხელახალი შეფუთვა ინარჩუნებს კოდეკს, ხოლო ტრანსკოდირება ხელახლა კოდირებს მას თავსებადობისთვის, და მხოლოდ მეორე ხარჯავს სერიოზულ CPU-ს. არც ერთი არ ხდება საჭირო მხოლოდ იმიტომ, რომ გზაზე VPN არის.

დაგეგმეთ ასვლის ხაზი იმის მიხედვით, სად ხდება გავრცელება. ერთი კერძო მიღება, რომელიც კვებავს საჯარო მედია სერვისს, სულ სხვაგვარად იქცევა, ვიდრე ყოველი მაყურებელი, რომელიც თავის ნაკადს გვირაბის გავლით ექაჩება. მეორე ნიმუში ჩვეულებრივ მთავრდება გაჯერებული სახლის კავშირით და კამერით, რომელიც თითქოს შემთხვევით ფუჭდება.

ავთენტიფიკაცია მოათავსეთ იმ კიდეზე, რომელსაც აქვეყნებთ

TLS, მაყურებელთა ავთენტიფიკაცია და წვდომის ჟურნალირება საჯარო შესვლის წერტილს ეკუთვნის და არა კამერას. ეს კამერის წვდომის მონაცემებს ჰყოფს ნაკადის წვდომის მონაცემებისგან. ეს ასევე გაძლევთ ერთ ადგილს წვდომის გასაუქმებლად, როცა აუდიტორიის წევრი მიდის. ამ კონტროლების კამერაზე დაყენება სამაგიეროდ ნიშნავს, რომ აუდიტორიის ყოველი ცვლილება ხდება ადმინისტრაციული ცვლილება მოწყობილობაზე, რომელიც არასოდეს უნდა იყოს საჯაროდ ხელმისაწვდომი.

შეინახეთ VPN და კამერის ადმინისტრაციული ნებართვები გამოქვეყნების გზისგან განცალკევებით. VPS, რომელსაც შეუძლია კამერის ვებ ინტერფეისამდე მისვლა ნაკადის ჩამოსაქაჩად, არ უნდა იყოს ასევე ის მანქანა, რომელიც ამ ინტერფეისს ამჟღავნებს. აუდიტორიამ კამერის მისამართი არასოდეს უნდა იცოდეს.

შემდეგ გადაამოწმეთ ის ორი ბოლო, რომლებიც ნამდვილად ააშენეთ, ნაცვლად იმისა, რომ ვივარაუდოთ, რომ ჯაჭვი მუშაობს:

$ 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

კერძო წყაროს წარმატებული შემოწმება და დაკვრის სიის წარმატებული ჩამოტანა საჯარო კიდეზე ამტკიცებს დიზაინის სხვადასხვა ნახევარს. გამოსცადეთ ისინი ცალ-ცალკე. დაკვრა იმავე ტიპის კლიენტიდან, რომელსაც თქვენი აუდიტორია იყენებს, ერთადერთი ტესტია, რომელიც მთელ ჯაჭვს ფარავს.

საბოლოოდ გაქვთ ჯაჭვი, რომლის ყოველ რგოლს აქვს დანიშნულება: კერძო წყარო, შეზღუდული მიღება, არჩეული შეფუთვა, უფლებამოსილი მაყურებლის შესვლა. ამ რგოლთაგან არც ერთი არ არის სურვილისამებრი და არც ერთი არ იქმნება პორტის გახსნით.