Pewne informacje zawarte w artykule wymagają weryfikacji. Zajrzyj na stronę dyskusji, by dowiedzieć się, jakie informacje budzą wątpliwości.

RTSP (ang. Real Time Streaming Protocol) jest protokołem poziomu aplikacji, mającym 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 zaledwie jego propozycją ulegającą ciągłym zmianom oraz korektom (ang. draft). Protokół RTSP dostarcza użytkownikowi jakby elastycznego szkieletu, bazy, która bywa rozwijana oraz dopasowywana do potrzeb użytkownika, aby umożliwić sterowanie transmisją na żądanie danych czasu rzeczywistego takich jak audio oraz wideo. Źródła danych potrafią 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 równocześnie wielu sesji transmisji danych, dostarczając środki do wyboru kanału transportowego jak np. UDP, rozgałęziany UDP oraz TCP oraz środki do wyboru odpowiednich mechanizmów działania opartych o protokół RTP.

Protokół RTSP tworzy oraz steruje pojedynczymi albo wielokrotnymi strumieniami ciągłych danych takich jak audio oraz 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 jest pojęcie połączenia. Zamiast tego przyjmuje się, że serwer RTSP utrzymuje sesje oznaczoną odpowiednim identyfikatorem, która łączy grupy strumieni mediów oraz 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ć oraz 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 albo niepewnego bezpołączeniowego protokołu transportowego UDP. Strumienie sterowane przez protokół RTSP potrafią 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 oraz w wielu ważnych kwestiach różni się od niego:

• Protokół RTSP wprowadza wiele nowych metod oraz ma odmienny identyfikator protokołu,
• Dla protokołu RTSP jest 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 potrafią posłużyć do modyfikacji kolejnych żądań, w przeciwieństwie od bezstanowej natury protokołu HTTP (informacje w konkretnym żądaniu nie bywają wiązane z innymi, więc nie da się ich dalej stosować),
• Zarówno serwer RTSP jak oraz użytkownik potrafią wysyłać żądania w przeciwieństwie do protokołu HTTP, który jest asymetryczny tzn. użytkownik wysyła żądania a serwer odpowiada,
• Dane są transportowane przez odmienny protokół. Informacje opisujące sesje wracają w postaci „odpowiedzi opisowej” oraz w przypadku używania protokołu TCP bywają przeplatane ze strumieniem danych transportowanych przez protokół RTP.

Protokół RTSP dopuszcza 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 albo w odmienny sposób. Jeżeli prezentacja ma formę transmisji rozgałęzionej (ang. multicast), informacje opisujące sesje zawierają adresy typu rozgałęzionego oraz porty dedykowane dla danych o charakterze ciągłym. Jeżeli informacje przesyłane są zaledwie do pojedynczego odbiorcy (ang. unicast), odbiorca wyznacza 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 bywają 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 bywa 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, kiedy dane przesyłane są z użyciem protokołu UDP. Tym sposobem dane dostarczane są nieprzerwanie, nawet kiedy żądania RTSP nie zostaną odebrane przez serwer mediów. Równocześnie pojedynczy strumień mediów bywa kontrolowany przez żądania RTSP wysyłane sekwencyjnie na zróżnicowane 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ń oraz użycia zasobów strumienia na serwerze:

• SETUP – powoduje umieszczenie zasobów serwera w strumieniu oraz założenie 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.

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 także współpracować z protokołem HTTP w inicjalizowaniu kontaktu z zawartością strumienia przez stronę internetową, co wielokrotnie ma miejsce.

Dla przesyłania danych, przeważajaca ilość 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 wyłącznym z którym może współpracować).

Oto parę 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

• RFC 2326 - Real Time Streaming Protocol (RTSP)