W klasycznej usłudze telewizji cyfrowej (DVB-T, DVB-C, DVB-S) sygnał jest nadawany jednokierunkowo: od nadawcy do odbiorcy. Mówi się, że jest to transmisja typu broadcast lub multicast, gdzie setki czy tysiące użytkowników odbierają ten sam strumień danych, a odbiornik (dekoder, telewizor z tunerem DVB) nic nie odsyła z powrotem do sieci. I właśnie dlatego do samego odbioru telewizji cyfrowej nie jest potrzebna transmisja zwrotna, czyli tzw. kanał zwrotny. W praktyce wygląda to tak, że operator kablowy, satelitarny albo naziemny emituje strumień MPEG-TS z wieloma programami, zakodowany według standardów DVB i kompresji wideo (H.264/AVC, czasem HEVC), a odbiornik tylko „słucha” tego strumienia i wybiera odpowiedni kanał, ale nie prowadzi żadnego dialogu z serwerem. Kanał zwrotny zaczyna być potrzebny dopiero przy usługach interaktywnych, jak np. zamawianie VOD, EPG z funkcjami sieciowymi, głosowania w teleturniejach, aplikacje HbbTV czy różne „smart” dodatki. Natomiast samo przełączanie zwykłych kanałów telewizyjnych odbywa się wyłącznie lokalnie – odbiornik zmienia PID-y i częstotliwość, ale nie wysyła żadnej informacji do nadawcy. Z mojego doświadczenia w sieciach kablowych mówi się wręcz, że „goły DVB” to usługa bezinterakcyjna, a dopiero gdy dołożymy modem kablowy DOCSIS albo inną ścieżkę IP, pojawia się prawdziwy kanał zwrotny. W dobrze zaprojektowanej sieci jest to rozdzielone: warstwa broadcastu TV i osobno warstwa IP dla usług interaktywnych. To właśnie odróżnia tradycyjną telewizję cyfrową od usług takich jak VoD, Time Shift czy dostęp do Internetu, gdzie komunikacja dwukierunkowa jest absolutnym wymogiem technicznym.
Wiele osób intuicyjnie zakłada, że skoro oglądamy coś „przez sieć”, to zawsze musi istnieć kanał zwrotny. I stąd biorą się pomyłki przy tego typu pytaniach. Warto uporządkować pojęcia: kanał zwrotny, czyli transmisja zwrotna, jest potrzebny wtedy, gdy odbiornik musi wysłać do sieci jakieś żądanie: wybór konkretnego pliku, przesunięcie w czasie, potwierdzenie logowania, pobranie spersonalizowanych danych. W usługach typu Time Shift użytkownik decyduje, kiedy zatrzymać, przewinąć czy wznowić program. Technicznie oznacza to sterowanie strumieniem po stronie serwera lub korzystanie z bufora w sieci operatora. Żeby to zadziałało, terminal musi wysyłać komendy – play, pause, seek – więc bez dwukierunkowej komunikacji się nie da. Podobnie w Video on Demand: użytkownik wybiera konkretny materiał z katalogu, często płatny, a serwer musi o tym „wiedzieć”. Cały mechanizm to tak naprawdę klasyczna usługa klient–serwer oparta na protokołach IP, gdzie klient zgłasza żądanie, a serwer odpowiada odpowiednim strumieniem wideo. Brak kanału zwrotnego uniemożliwiłby samo zamówienie tego materiału, nie mówiąc już o rozliczeniu czy autoryzacji. Jeszcze wyraźniej widać to przy dostępie do Internetu. Tutaj wymóg transmisji zwrotnej jest absolutny, bo każde otwarcie strony WWW, każde wysłanie pakietu TCP czy UDP wymaga wymiany danych w obie strony. Bez kanału zwrotnego nie byłoby ani zapytań DNS, ani ustanowienia sesji TCP (trzyetapowy handshake), ani żadnej sensownej komunikacji w warstwie aplikacji. Typowym błędem myślowym jest wrzucanie do jednego worka wszystkich usług „telewizyjno-internetowych” i traktowanie ich jak prostego nadawania sygnału. Tymczasem tradycyjna telewizja cyfrowa to jednostronny broadcast, a Time Shift, VoD i Internet to usługi z natury interaktywne, ściśle powiązane z kanałem zwrotnym i protokołami IP. Jeżeli pomylisz te pojęcia, to potem trudno poprawnie zaprojektować sieć, dobrać sprzęt CPE czy choćby poprawnie zdiagnozować problemy z usługami interaktywnymi.