Real Time Streaming Protocol

Ten artykuł od 2021-11 wymaga zweryfikowania podanych informacji. Należy podać wiarygodne źródła w formie przypisów bibliograficznych. Część lub nawet wszystkie informacje w artykule mogą być nieprawdziwe. Jako pozbawione źródeł mogą zostać zakwestionowane i usunięte. Sprawdź w źródłach: Encyklopedia PWN • Google Books • Google Scholar • Federacja Bibliotek Cyfrowych • BazHum • BazTech • RCIN • Internet Archive (texts / inlibrary) Dokładniejsze informacje o tym, co należy poprawić, być może znajdują się w dyskusji tego artykułu. Po wyeliminowaniu niedoskonałości należy usunąć szablon {{Dopracować}} z tego artykułu.

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.