RTSP (Real Time Streaming Protocol)

Protokół RTSP steruje przesyłaniem strumieniowym w Internecie. Wyłonił się z prac Columbia University i firm Netscape oraz RealNetworks, po czym został przedłożony IETF, gdzie jest bardzo znacznie uzupełniany i poszerzany. RTSP nosi również nazwę protokołu sterowania prezentacji multimedialnej typu klient-serwer. RTSP jest protokołem sterowania, który inicjuje dostarczeniem strumieni multimedialnych z serwerów medialnych (strumieniowych) i kieruje nimi. Szczególnie ważne jest synchronizowanie wielu strumieni i przypisanie każdemu stosownego protokołu transportowego, zwykle RTP, IP Multicast z RTP, UDP, rzadziej TCP i niestandardowych. Natomiast RTSP nie dostarcza danych (chociaż połączenie RTSP może być użyte do tunelowania ruchu RTP dla łatwiejszego użycia z zaporami sprzętowymi oraz innymi urządzeniami sieciowymi). RTP i RTSP są często stosowane razem, ale mogą być używane rozłącznie. RTSP, podobnie jak H.323, używa RTP do formatowania pakietów z zawartością multimedialną. Jeżeli jednak H.323 obsługuje wideokonferencje grup o umiarkowanej wielkości, to RTSP jest przeznaczony do sprawnego rozgłaszania danych audiowizualnych zarówno do niewielkich, jak i dużych grup. RTSP jest protokołem typu out-of-band, umożliwiającym urządzeniom odtwarzającym sterowanie przepływem strumieniowym. Out-of-band oznacza, że wiadomości RTSP są przesłane osobnym kanałem, wydzielonym z pasma dla strumieni danych. Kompresją, kapsułkowaniem pakietów, ich transportem czy buforowaniem zajmują się inne protokoły, ale nie RTSP. Podstawową jednostką komunikacyjną RTSP jest wiadomość. Ma ona strukturę sekwencji bajtów odpowiadającą ściśle zdefiniowanej składni. Wiadomości są transmitowane za pośrednictwem protokołów bezpołączeniowych lub połączeniowych. Między RTSP i HTTP istnieje wiele podobieństw: format protokołu (tekst, nagłówki MIME), mechanizmy bezpieczeństwa, kody statusu, format URL, negocjowanie zawartości i składnia poleceń oraz odpowiedzi (request, response). Ogólna składnia dla metod RTSP ma postać: {method name} {URL} {protocol version}CRLF {parameters}

Przykład polecenia (request) RTSP: DESCRIBE http://idg.networld.com/aj1.rm RTSP/1.0 Cseq: 312 Accept: application/sdp, application/mheg

Cseq jest numerem sekwencyjnym dla par polecenie–odpowiedź, a sdp i mheg symbolami protokołów SDP (Session Description Protocol) i MHEG (Multimedia and Hypermedia Experts Group). Każde polecenie RTSP powoduje wysłanie odpowiedzi (response) o następującej składni ogólnej: {protocol version} {status code} {reason-phrase}CRLF {parameters} Przykład: RTSP/1.0 200 OK.. Cseq: 312

Wiadomość RTSP może zawierać szerszą treść (body). Składnia ogólna ma wtedy postać: {method name} {URL} {protocol version}CRLF {MIME header field}CRLF … {MIME header field}CRLF CRLF {optional body, depending on the presence of a ”Content-length”} (wolumen treści opcjonalnej, zależny od obecności pola nagłówka Content-length). RTSP musi używać protokołu transportowego. Wbrew pozorom wspomniane podobieństwa z HTTP nie mają zbyt wiele wspólnego z ich współpracą. Specyfika transmisji strumieniowej polega na tym, że urządzenie odtwarzające muzykę czy film z serwera medialnego czyni to bez pośrednictwa dysku twardego. W cały proces odtwarzania angażuje się bezpośrednio karta graficzna i dźwiękowa. Zgubienie jednego czy dwóch pakietów może nie mieć znaczenia tylko wówczas, kiedy protokołem transportowym jest UDP czy RTP. Mechanizm PAR (pozytywnego potwierdzania z retransmisją), jaki stosuje TCP, może wprowadzić opóźnienia, które uniemożliwią zagwarantowanie odpowiedniej jakości transmisji. A na TCP opiera się HTTP. Z drugiej strony wolumen danych poleceń RTSP będzie prawdopodobnie niewielki, a więc kontrola przepływu TCP nie jest szczególnie przydatna, a może opóźnieniami destabilizować serwer strumieniowy i klientów. Przy UDP nawet ustalenie sesji jest szybsze, chociaż w istocie nie stanowi to zbyt ważnej kwestii – RTSP wymaga własnego setupu. Streaming, czyli przesyłanie strumieniowe, dzieli dane na wiele pakietów, których rozmiar zależy od dostępnego pasma między klientem a serwerem. Oprogramowanie użytkownika może równocześnie odtwarzać jeden pakiet, dekompresować drugi i przyjmować trzeci. Można więc zacząć odtwarzanie prawie natychmiast, bez czekania na zakończenie ładowania całego pliku medialnego. Eródła danych dla przesyłania strumieniowego to nie tylko wspomniane pliki pobierane z serwera medialnego, ale i wszelkie środki transmisji na żywo. W tych okolicznościach RTSP jest postrzegany bardziej jako struktura niż protokół. Jest przeznaczony do sterowania wieloma sesjami dostarczania danych oraz dostarczania mechanizmów opartych na RTP. Ale danych multimedialnych nie dostarcza. Funkcjonuje niejako na szczycie RTP, z którego steruje dostarczaniem zawartości w czasie rzeczywistym. Dzięki temu implementacje RTSP będą zdolne wykorzystać każde ulepszenia RTP, takie jak nowy protokół kompresji nagłówka RTP. RTSP może też być użyty z RSVP do ustalania i zarządzania sesjami przesyłania strumieni z zarezerwowanym pasmem.