Obecnie na całym świecie stale rośnie liczba inteligentnych kamer wideo zbierających i przesyłających strumieniowo wideo. Oczywiście wiele z tych kamer jest wykorzystywanych do celów bezpieczeństwa.

W rzeczywistości oczekuje się, że globalny rynek nadzoru wideo osiągnie 83 mld USD w ciągu najbliższych pięciu lat. Ale oprócz bezpieczeństwa istnieje wiele innych zastosowań, w tym praca zdalna, edukacja online i cyfrowa rozrywka.

Wśród różnych technologii napędzających te przypadki użycia, Web Real-Time Communication (WebRTC) i Real-Time Streaming Protocol (RTSP) wyróżniają się jako dwie najlepsze opcje. Oto, co należy wiedzieć o WebRTC vs. RTSP i ich przydatności do różnych potrzeb związanych z przesyłaniem strumieniowym.

Podstawy WebRTC

Zacznijmy od WebRTC, który jest protokołem komunikacyjnym umożliwiającym strumieniowe przesyłanie dźwięku i obrazu w czasie rzeczywistym bezpośrednio w przeglądarkach internetowych. Google opracowało WebRTC, ale obecnie jest to projekt open-source z szerokim wsparciem i dokładną dokumentacją.

Podczas nawiązywania połączenia wideo za pośrednictwem przeglądarki, WebRTC obsługuje transmisję danych wideo i audio do osoby, do której dzwonimy, i odwrotnie. Nie trzeba więc pobierać specjalistycznego oprogramowania komunikacyjnego, takiego jak Skype; można po prostu rozmawiać przez przeglądarkę za pomocą czegoś takiego jak Google Meet.

Funkcje WebRTC

WebRTC ma kilka cech, które go wyróżniają. Po pierwsze, protokół ten dostosowuje jakość połączenia w zależności od szybkości łącza internetowego. Wideo może więc być niewyraźne, jeśli prędkość Internetu jest niska, ale zazwyczaj nie trzeba się martwić o utratę połączenia. Protokół szyfruje również strumienie danych, zarówno przychodzące, jak i wychodzące, co oznacza, że strumienie wideo są prywatne i bezpieczne. I wreszcie, zapewnia on kanał danych do wysyłania plików lub czatu tekstowego, więc nie ogranicza się tylko do wideo.

Być może najważniejszym aspektem WebRTC jest to, że jest to peer-to-peer (P2P), co oznacza, że nie musi przechodzić przez serwer. Umożliwia to wyższą wydajność i niższe opóźnienia, lub tak “w czasie rzeczywistym”, jak to tylko możliwe w Internecie (podróżowanie bezpośrednio z punktu A do punktu B). Komunikacja P2P przypomina wysyłanie listu do przyjaciela, który mieszka zaledwie dwie godziny drogi stąd. Mógłby Pan wysłać list za pośrednictwem poczty, ale zawsze istnieje ryzyko, że list zostanie opóźniony w różnych punktach.

Jeśli zamiast tego przekaże Pan list bezpośrednio swojemu przyjacielowi, może mieć Pan pewność, że dotrze on do niego w ciągu zaledwie dwóch godzin, a nie kilku tygodni. Komunikacja P2P jest więc bardziej bezpośrednia i ogólnie szybsza niż komunikacja oparta na serwerach.

Jak działa WebRTC

Komunikacja P2P za pośrednictwem WebRTC obejmuje kilka kroków technicznych. Pierwszym z nich jest sygnalizacja. Proszę pomyśleć o sygnalizacji WebRTC jako o procesie organizowania spotkania. Zanim dwie osoby się spotkają, muszą wymienić się informacjami, takimi jak czas spotkania, lokalizacja i agenda. Podobnie w WebRTC, sygnalizacja jest początkową fazą aranżacji, w której dwa urządzenia wymieniają informacje niezbędne do ustanowienia sesji komunikacyjnej w czasie rzeczywistym.

Następnym krokiem jest przechwytywanie multimediów, które umożliwia przeglądarce dostęp do kamery i mikrofonu urządzenia w celu gromadzenia danych strumieniowych, takich jak wideo i audio.

Następnym krokiem jest translacja adresów sieciowych (NAT). NAT to metoda używana przez routery do tłumaczenia prywatnych adresów IP w sieci lokalnej na pojedynczy publiczny adres IP w celu uzyskania dostępu do Internetu. Przypomina to pojedynczy adres pocztowy używany dla wszystkich urządzeń w domu. NAT traversal, z drugiej strony, jest techniką, która pozwala urządzeniom znajdującym się za różnymi NAT-ami na ustanowienie bezpośrednich połączeń peer-to-peer. Przypomina to zorganizowanie bezpośredniej linii komunikacyjnej między dwoma domami, z których każdy ma własny unikalny system pocztowy, umożliwiając im ominięcie standardowej trasy pocztowej i bezpośrednie połączenie.

Gdy połączenie zostanie nawiązane, a przeglądarki nawiążą połączenie poprzez NAT traversal, następnym krokiem jest strumieniowe przesyłanie danych. Przez cały czas trwania połączenia, WebRTC utrzymuje stabilne połączenie, a następnie pod koniec sesji, protokół pozwala partnerom na bezpieczne zamknięcie połączeń – odpowiednik odłożenia telefonu na koniec rozmowy.

Kiedy używać WebRTC

Jedną z największych zalet WebRTC jest to, że działa on na wielu platformach i w różnych przeglądarkach. Jeśli więc korzystają Państwo na przykład z przeglądarki Chrome, ale Państwa znajomy używa przeglądarki Edge, nadal mogą Państwo przesyłać strumieniowo wideo. Jest też łatwo dostępny. W przeciwieństwie na przykład do Skype’a, nie trzeba pobierać osobnej aplikacji. Wystarczy otworzyć łącze bezpośrednio w przeglądarce.

Niektóre sytuacje, w których można korzystać z WebRTC, obejmują strumieniowanie różnych wydarzeń, takich jak koncerty, wydarzenia sportowe, interaktywne seminaria internetowe, udostępnianie poufnych plików lub danych między przeglądarkami, przesyłanie strumieniowe materiału wideo z inteligentnej kamery do przeglądarki lub gry wieloosobowe w czasie rzeczywistym.

Zrozumienie RTSP

Protokół przesyłania strumieniowego w czasie rzeczywistym (RTSP) nie jest dokładnie protokołem przesyłania strumieniowego wideo, takim jak WebRTC. Zamiast tego jest to protokół kontroli sieci. Innymi słowy, można go używać do wysyłania poleceń odtwarzania wideo, takich jak odtwarzanie, pauza itp. tak samo, jak w przypadku ręcznego pilota do urządzenia do przesyłania strumieniowego.

Tak więc, w przeciwieństwie do WebRTC, RTSP służy jedynie do ustanawiania i kontrolowania strumienia multimediów, a nie jest faktycznym nośnikiem, który go dostarcza. Rozpoczyna sesję strumieniowania, a następnie umożliwia klientom zdalne sterowanie strumieniem. Na przykład, w inteligentnym systemie nadzoru, RTSP pozwala na uruchamianie i zatrzymywanie strumienia wideo z kamery bezpieczeństwa w czasie rzeczywistym, dzięki czemu polecenia niemal natychmiast docierają do urządzenia, którym próbujemy sterować.

Funkcje RTSP

RTSP z natury nie jest protokołem P2P, choć w niektórych przypadkach może być używany w tym kontekście. Ogólnie rzecz biorąc, RTSP wysyła polecenia za pośrednictwem serwera, który hostuje i strumieniuje zawartość multimedialną, więc serwer faktycznie wykonuje większość pracy, podczas gdy RTSP jedynie wysyła polecenia. Serwer niekoniecznie jest serwerem w chmurze; może to być serwer “logiczny” (jak w paradygmacie klient-serwer), więc serwer RTSP może działać na kamerze IP w sieci prywatnej. RTSP służy jedynie do kontrolowania odtwarzania i rozpoczynania lub zatrzymywania strumienia, a nie do faktycznego dostarczania multimediów.

Tak więc, w celu rzeczywistego strumieniowego przesyłania multimediów, należy sparować RTSP z innymi protokołami. Najpopularniejszym z nich jest protokół RTP (Real-Time Transport Protocol). Protokół RTP służy do przesyłania strumieniowego i dostarczania danych audio i wideo.

Oprócz RTP, RTSP często łączy się z protokołem kontroli transmisji (TCP), który umożliwia RTSP przesyłanie poleceń przez Internet. TCP koncentruje się na niezawodności i retransmituje wszelkie utracone lub uszkodzone pakiety, więc jest używany w połączeniu z RTSP w sytuacjach, w których niezawodność jest najważniejsza. Jeśli połączenie strumieniowania wideo musi zostać ustanowione przez zaporę ogniową, deweloper może również wykonać tunelowanie TCP, aby ustanowić tunel oparty na p2p bez kłopotów z zaporą ogniową.

Jak działa RTSP z TCP

Zasadniczo RTSP wymaga dodatkowej konfiguracji w porównaniu do WebRTC, aby strumień mógł przejść przez zapory ogniowe. Deweloperzy mogą albo sami skonfigurować zapory sieciowe do odbierania strumieni RTSP, albo użyć tunelowania TCP, aby rozwiązać ten problem.

Tunelowanie TCP to technika, która pozwala systemowi wideo ominąć zapory sieciowe. Podczas tunelowania TCP zapora nie widzi ruchu TCP. Zamiast tego usługa tunelowania TCP przesyła pakiety UDP przez zaporę, “tłumacząc” te pakiety na/z TCP na każdym końcu tunelu, tj. w aplikacjach po obu stronach (klient i urządzenie/serwer).

Tak więc w wielu scenariuszach wideo RTSP/TCP jest trybem, który ma najlepszy sens, pomimo spadku wydajności wynikającego z korzystania z niezawodnego transportu.

Kiedy używać RTSP

Wiele starszych modeli kamer monitorujących ma wbudowane serwery RTSP w stosie oprogramowania do natywnej obsługi strumienia wideo z kamery. Jeśli integrują Państwo taką kamerę ze swoim systemem, zwykle używają Państwo tunelowania RTSP + TCP. Z drugiej strony, jeśli mają Państwo nowszy stos oprogramowania kamery z obsługą protokołów wideo WebRTC, prawdopodobnie użyliby Państwo tego. Zależy to jednak również od tego, co obsługuje Państwa backend i oprogramowanie pośredniczące. RTSP jest przydatny w systemach, w których użytkownicy chcą kontrolować odtwarzanie wideo ze zdalnej lokalizacji, na przykład w przypadku zabezpieczeń domowych lub przesyłania strumieniowego z dronów.

Przypadki użycia

WebRTC początkowo był przeznaczony wyłącznie do komunikacji między przeglądarkami, więc początkowo nie był idealny do sytuacji, w których chcesz, powiedzmy, sterować kamerą wideo ze smartfona lub przeglądać kanał za pośrednictwem aplikacji. Teraz jednak WebRTC jest kompatybilny z aplikacjami IoT i Android, a także oprogramowaniem do łączności IoT. Tymczasem protokoły RTSP i RTP nie mają takich funkcji bezpieczeństwa ani niskiego opóźnienia jak WebRTC, ale ich bezpieczeństwo można zwiększyć, gdy są używane z Tunelowanie TCP.

W wyniku wszystkich swoich wyspecjalizowanych funkcji, WebRTC jest najczęściej wykorzystywany w sytuacjach IoT do dwukierunkowej komunikacji, takich jak spotkania telemedyczne, praca zdalna i inne scenariusze wideokonferencji, a teraz także do kontroli nadzoru wideo na urządzeniach mobilnych. Z kolei RTSP/RTP jest wykorzystywany głównie w kamerach bezpieczeństwa i transmisji z jednego źródła do wielu urządzeń.

Przemyślenia końcowe

Wybór między WebRTC a RTSP to skomplikowany temat, a wiele różnych czynników może mieć wpływ na to, który protokół zostanie wybrany. Ostatecznie jednak oba są ważnymi częściami ekosystemu IoT – szczególnie w zakresie strumieniowania wideo.