Real Time Streaming Protocol

RTSP (ang. Real Time Streaming Protocol) – protokół poziomu aplikacji mający za zadanie sterowanie dostarczaniem danych czasu rzeczywistego. Mimo że jest on wręcz powszechnie stosowany w aplikacjach związanych z przesyłaniem danych multimedialnych (pierwszy dokument RFC datowany jest na kwiecień 1998), nie jest on jeszcze ustanowionym oficjalnie standardem, lecz jedynie jego propozycją ulegającą ciągłym zmianom i korektom (ang. draft). Protokół RTSP dostarcza użytkownikowi jakby elastycznego szkieletu, bazy, która może być rozwijana i dopasowywana do potrzeb użytkownika, aby umożliwić sterowanie transmisją na żądanie danych czasu rzeczywistego takich jak audio i wideo. Źródła danych mogą zawierać dane dwojakiego rodzaju: materiały odtwarzane „na żywo” oraz gromadzone w bazie danych do późniejszego odtworzenia. Protokół w założeniu jego twórców (m.in. firma RealNetworks) ma służyć kontroli jednocześnie wielu sesji transmisji danych, dostarczając środki do wyboru kanału transportowego jak np. UDP, rozgałęziany UDP i TCP oraz środki do wyboru odpowiednich mechanizmów działania opartych na protokole RTP.

Protokół RTSP tworzy i steruje pojedynczymi lub wielokrotnymi strumieniami ciągłych danych takich jak audio i wideo. Tłumacząc obrazowo, protokół RTSP ma być rodzajem sieciowego „pilota” (ang. network remote control) dla serwerów multimedialnych. W protokole tym w zasadzie nie występuje pojęcie połączenia. Zamiast tego przyjmuje się, że serwer RTSP utrzymuje sesję oznaczoną odpowiednim identyfikatorem, która łączy grupy strumieni mediów i ich stanów. Sesja protokołu RTSP nie jest związana z pojęciem połączenia na poziomie warstwy transportowej w rozumieniu połączenia TCP. Podczas sesji użytkownik może otwierać i zamykać wiele pewnych (w znaczeniu niezawodnych) połączeń transportowych z serwerem, aby wysyłać żądania protokołu RTSP dla tej sesji.

Protokół RTSP może używać protokołu transportowego TCP gwarantującego niezawodne połączenie lub niepewnego bezpołączeniowego protokołu transportowego UDP. Strumienie sterowane przez protokół RTSP mogą używać protokołu RTP do transportu swoich danych, ale operacje protokołu RTSP nie zależą w żaden sposób od mechanizmów transportowych używanych do transmisji ciągłych danych. Protokół RTSP w wielu aspektach podobny jest do protokołu HTTP (ang. HyperText Transfer Protocol), ale i w wielu ważnych kwestiach różni się od niego:

• Protokół RTSP wprowadza wiele nowych metod i posiada odmienny identyfikator protokołu,
• Dla protokołu RTSP występuje pojęcie sesji wbudowanej w protokół,
• Protokół RTSP jest protokołem stanowym (ang. stateful), co oznacza, że informacje zawarte w jednym żądaniu wysłanym od nadawcy do adresata mogą posłużyć do modyfikacji kolejnych żądań, w odróżnieniu od bezstanowej natury protokołu HTTP (informacje w konkretnym żądaniu nie mogą być wiązane z innymi, więc nie można ich dalej stosować),
• Zarówno serwer RTSP, jak i użytkownik mogą wysyłać żądania w odróżnieniu od protokołu HTTP, który jest asymetryczny, tzn. użytkownik wysyła żądania, a serwer odpowiada,
• Dane są transportowane przez inny protokół. Informacje opisujące sesje wracają w postaci „odpowiedzi opisowej” i w przypadku używania protokołu TCP mogą być przeplatane ze strumieniem danych transportowanych przez protokół RTP.

Protokół RTSP umożliwia następujące operacje

• Pozyskiwanie danych z serwera danych. Klient może zażądać, aby informacje opisujące sesje zostały przesłane z użyciem RTSP DESCRIBE, protokołu HTTP lub w inny sposób. Jeżeli prezentacja ma formę transmisji rozgałęzionej (ang. multicast), informacje opisujące sesje zawierają adresy typu rozgałęzionego i porty przeznaczone dla danych o charakterze ciągłym. Jeżeli informacje przesyłane są jedynie do pojedynczego odbiorcy (ang. unicast), odbiorca określa miejsce odbioru danych z uwagi na ich bezpieczeństwo.
• „Zaproszenie” serwera danych do sesji. Serwer mediów może zostać „zaproszony” do udziału w trwającej konferencji w celu odtworzenia danych dla potrzeb użytkowników. Ten sposób pracy jest szczególnie użyteczny dla aplikacji uczących (nauka via Internet).

Rodzaje pracy protokołu RTSP

• Przesłanie pojedyncze (ang. unicast). Media są transmitowane do źródła, które wysłało żądanie RTSP z wykorzystaniem numeru portu wybranego przez klienta. Alternatywnie media mogą być transmitowane w tym samym niezawodnym strumieniu co RTSP,
• Przesłanie rozgałęzione (ang. multicast) z wybraniem adresu przez serwer. Serwer mediów wybiera adres rozgałęziony oraz port docelowy. Jest to bardzo typowe dla transmisji prawie na żądanie (ang. nVoD – near Video-on-Demand),
• Przesłanie rozgałęzione z wybraniem adresu przez klienta. Jeżeli serwer jest zaangażowany w trwającą konferencję typu rozgałęzionego, adres rozgałęziony, port oraz klucz szyfrujący dostarczane wraz z opisem konferencji (opisem prezentacji).

Protokół RTSP steruje strumieniem, który może być przesyłany za pomocą odrębnego protokołu, niezależnego od kanału kontrolnego. Np. sterowanie RTSP może pojawiać się w połączeniu TCP, gdy dane przesyłane są z użyciem protokołu UDP. Tym sposobem dane dostarczane są nieprzerwanie, nawet gdy żądania RTSP nie zostaną odebrane przez serwer mediów. Równocześnie pojedynczy strumień mediów może być kontrolowany przez żądania RTSP wysyłane sekwencyjnie na różne połączenia TCP. Jednakże serwer musi zachowywać tzw. stan sesji, by móc dobrze kontrolować współdziałanie żądań RTSP ze strumieniem.

Poniżej przedstawiono sposoby (komendy) odgrywające główną rolę w definiowaniu przemieszczeń i użycia zasobów strumienia na serwerze:

• SETUP – powoduje umieszczenie zasobów serwera w strumieniu i utworzenie sesji RTSP,
• PLAY – uruchamia transmisję danych zawartych w strumieniu po wcześniejszej komendzie SETUP,
• PAUSE – okresowo zatrzymuje strumień (transmisję) bez zwalniania zasobów serwera,
• REDIRECT – wykrywa, że sesja powinna zostać przeniesiona na nowy serwer (do innego miejsca),
• PING – chroni sesje przed przeterminowaniem (ang. timeout),
• TEARDOWN – zwalnia zasoby serwera połączone ze strumieniem. Sesja RTSP zostaje przerwana.
• GET_PARAMETER – pobiera wartości wybranych parametrów dla URI, może być użyte do testowania dostępności klineta lub serwera
• SET_PARAMETER – ustawia wartości wybranych paramertów dla URI
• OPTIONS
• DESCRIBE
• RECORD
• ANNOUNCE

Komendy używane przez protokół RTSP wykorzystują pola nagłówka sesji, aby zidentyfikować sesję RTSP, której stan jest zmieniany. Serwer generuje identyfikatory sesji w odpowiedzi na żądania SETUP.

Protokół RTSP ma wiele funkcji pokrywających się z protokołem HTTP. Może on również współpracować z protokołem HTTP w inicjalizowaniu kontaktu z zawartością strumienia przez stronę internetową, co często ma miejsce.

Dla przesyłania danych, większość mediów czasu rzeczywistego wykorzystuje protokół RTP jako protokół transportowy. Jakkolwiek protokół RTSP bardzo dobrze współpracuje z protokołem RTP, nie jest do niego przypisany (nie jest z nim związany jako z jedynym, z którym może współpracować).

Oto kilka najważniejszych zastosowań protokołu RTSP:

• Odtwarzanie przechowywanych danych na żądanie,
• Dystrybucja pojedynczego przesłania (do jednego użytkownika) przekazów „na żywo”,
• Zapraszanie serwerów „na żądanie” do grup rozgałęzionych,
• Rozgałęzione odtwarzanie na żądanie.

Linki zewnętrzne

• H.H. Schulzrinne H.H., A.A. Rao A.A., R.R. Lanphier R.R., Real Time Streaming Protocol (RTSP), RFC 2326, IETF, kwiecień 1998, DOI: 10.17487/RFC2326, ISSN 2070-1721, OCLC 943595667  (ang.).