Real Time Streaming Protocol

Real Time Streaming Protocol (RTSP), eğlence ve iletişim sistemlerinde medya sunucularındaki verilerin akışını kontrol etmek için tasarlanan bir ağ denetim protokolüdür. Bu protokol bitiş noktaları arasındaki medya bağlantılarının kurulması ve kontrol edilmesinde kullanılır. Medya sunucularının sorunu VCR'lerdeki gibi müşterilerin sunucudan alınan medya dosyalarını çalışma, durdurma gibi kısacası gerçek zamanlı kontrolü kolaylaştırmak.

Kendi veri akışının iletimi RTSP protokolünün görevi değildir. Çoğu RTSP sunucuları medya akışının dağıtımı için Gerçek Zamanlı Aktarım Protokolü (RTP) kullanır. Ancak bazı sunucular özel taşıma protokolü uygulamaktadır. Realnetworks'daki RTSP sunucusu örnek olarak, ayrıca RDT veri akışını taşıma özelliğinide bulunmaktadır.

RTSP 1998 yılında Internet Engineering Task Force(Internet Mühendisliği Görev Gücü ) (IETF) deki Multiparty Multimedia Session Control Working Group (MMUSIC WG) tarafından geliştirilmiş ve RFC 2326 olarak yayınlandı.

RTSP, HTTP'ye benzer, ancak özellikle akış ortamının kontrolü için tasarlanmıştır. Bir istemcinin bir sunucuya "oynat", "duraklat" ve "kaydet" gibi komutlar vermesine izin verir ve aynı zamanda akış ortamının teslimi için de kullanılabilir. Örneğin, bir kullanıcı akışı yaptığı bir videoyu duraklattığında, RTSP kullanıcının videoyu duraklatma isteğini video akış sunucusuna iletir.

RTSP RealNetworks, Netscape ve Columbia Üniversitesi tarafından geliştirilmiştir. İlk taslak, Ekim 1996'da Netscape ve Progressive Networkstarafından IETF'ye sunuldu, ardından Columbia Üniversitesi'nden Henning Schulzrinne, Aralık 1996'da "RTSP՚" ("RTSP prime") sundu. İki taslak İnternet Mühendisliği Görev Gücü'nün (IETF ) Çok Taraflı Multimedya Oturum Kontrolü Çalışma Grubu (MMUSIC WG) tarafından standardizasyon için birleştirildi ve çalışma grubu tarafından daha fazla taslak yayınlandı.. RTSP için Önerilen Standart, 1998'de RFC 2326 olarak yayınlandı. RTSP 2.0, 2016'da RTSP 1.0'ın yerine RFC 7826 olarak yayınlandı. RTSP 2.0, RTSP 1.0'ı temel alır, ancak temel sürüm anlaşma mekanizması dışında geriye dönük uyumlu değildir ve bir "Önerilen Standart" olarak kalır.

Akış verilerinin iletimi, RTSP'nin bir görevi değildir. Çoğu RTSP sunucusu, medya akışı teslimi için Gerçek Zamanlı Kontrol Protokolü Real-time Control Protocol (RTCP) ile birlikte Gerçek Zamanlı Aktarım Protokolünü Real-time Transport Protocol (RTP) kullanır. Ancak, bazı satıcılar özel taşıma protokolleri uygular. Örneğin, RealNetworks'ün RTSP sunucu yazılımı da RealNetworks'ün tescilli Gerçek Veri Aktarımı'nı Real Data Transport (RDT) kullanıyordu.

RTPS protokolünün HTTP ile benzerlikleri vardır, ancak RTSP yeni isteklerde eklemektedir. HTTP durumsuz iken, RTSP bir durumsal protokolüdür. Oturum tanımlayıcısı oturumları takip etmek için kullanılır yani kalıcı TCP bağlantısı gerektiren durumlarda kullanılır. RTSP mesajları istemciden sunucuya gönderilir istisna olarak sunucunun hangi istemciye sonuç döndüreceğidir.

Açıklama isteği RTSP URL (rtsp://...) isteklerinive yönetilebilir cevap veri türlerini içerir. UDP ve TCP için taşımaları için RTSP protokolü için varsayılan port 554'dür. Bu cevap genellikle Session Description Protocol (SDP) formatında olup sunum açıklamaları içerir. Diğer şeylerin yanı sıra sunum açıklaması toplam URL leri ile kontrollü medya akışlarını listeler. Tipik bir durum da, her bir ses ve video için bir stream akışı bulunmaktadır.

SETUP isteği tek bir medya akışının nasıl taşınacağını belirtmektedir. Bu istek PLAY isteği gönderilmeden önce yapılmalıdır. İstek medya akış URL'sini ve taşıma belirteci içerir. Bu belirtec genellikle RTCP verilerisini(ses veya video) almak için yerel bir port içerir. Sunucu cevaplarımız genellikle seçilen parametrelerin onaylanması ve yanlış kısımların duzeltilmesidir. Toplu PLAY isteği gönderilmeden önce her medya akışı SETUP kullanılarak yapılandırılmış olması gerekir.

Oynatma bir veya tüm medya akışlarının çalınması isteğidir. Birçok çalma isteği gönderilerek PLAY isteği yığın haline getirilebilir. URL toplam bütün URL de olabilir(tüm medya akışlarını oynatmak için) veya tek bir medya akışı için gerekli URL de(sadece tek bir akışı oynatmak için) olabilir. Bununla ilgili bir aralıkta belirtilebilir. Hiç aralık belirtilmezse PLAY akışı baştan sona kadar oynatılır veya akış durdurulursa sonra durdurulduğu bu noktan aynen devam eder.

PAUSE isteği akışı geçici olarak durdurur veya tüm akış isteğini bir PLAY isteği gelince devam edicek şekilde erteler. İstek toplu veya medya akış URL si içerir. PAUSE zamanı bir dizi parametresi ile belirlenebilir. Dizi parametresi PAUSE yi hızlı bir şekilde değiştirebilir yani PAUSE yi kaldırabilir.

ANNOUNCE, istemciden sunucuya gönderildiğinde, istek URL'si tarafından tanımlanan bir sunumun veya medya nesnesinin açıklamasını bir sunucuya gönderir. ANNOUNCE, sunucudan istemciye gönderildiğinde, oturum açıklamasını gerçek zamanlı olarak günceller. Bir sunuma yeni bir medya akışı eklenirse (örneğin, canlı bir sunum sırasında), bileşenlerin silinebilmesi için yalnızca ek bileşenler yerine tüm sunum açıklamasının yeniden gönderilmesi gerekir.

GET_PARAMETER isteği, URI'de belirtilen bir sunumun veya akışın bir parametresinin değerini alır. Cevap ve cevabın içeriği uygulamaya bırakılmıştır. Hiçbir varlık gövdesi olmayan GET_PARAMETER, istemci veya sunucu canlılığını ("ping") test etmek için kullanılabilir.

Yönlendirme isteği, istemciye başka bir sunucu konumuna bağlanması gerektiğini bildirir. İstemcinin bu URL için istekte bulunması gerektiğini belirten zorunlu Konum başlığını içerir. Yönlendirmenin ne zaman etkili olacağını gösteren Range parametresini içerebilir. İstemci, bu URI için medya göndermeye veya almaya devam etmek istiyorsa, belirlenen ana bilgisayarda mevcut oturum için bir TEARDOWN isteği ve yeni oturum için bir KURULUM YAPMAK ZORUNDADIR.

Belirli güvenlik duvarı tasarımları ve diğer koşullar, bir sunucuyu RTSP yöntemlerini serpiştirmeye ve veri akışı yapmaya zorlayabilir. İstemci ve sunucu çalışmasını karmaşıklaştırdığından ve ek yük getirdiğinden, bu serpiştirmeden genellikle gerekli olmadıkça kaçınılmalıdır. Aralıklı ikili veriler yalnızca RTSP, TCP üzerinden taşınıyorsa KULLANILMALIDIR. RTP paketleri gibi akış verileri, bir ASCII dolar işareti (24 onaltılık), ardından bir baytlık bir kanal tanımlayıcısı ve ardından ağ bayt sırasına göre ikili, iki baytlık bir tamsayı olarak kapsüllenmiş ikili verilerin uzunluğu ile kapsüllenir. Akış verileri, CRLF olmadan, ancak üst katman protokol başlıkları dahil olmak üzere hemen ardından gelir. Her $ bloğu tam olarak bir üst katman protokol veri birimi, örneğin bir RTP paketi içerir.