Gerçek Zamanlı İletim Protokolü

RTP (Real-time Transport Protocol), gerçek zamanlı ses, görüntü ya da simülasyon verilerinin uçtan uca taşınmasını sağlayan protokoldür. Bu protokol IETF nin Audio-Video Transport çalışma grubu tarafından geliştirildi. RTP geniş ölçüde telefon, video telekonferans uygulamaları ve web tabanlı bas-konuş özellikleri gibi streaming media gerektiren iletişim ve görsel sistemlerde kullanılır.

RTP genellikle RTP Control Protocol (RTCP) ile beraber kullanılır. RTP media streamleri (audio ve video gibi) taşıyorken RTCP Quality of Service (QoS) bilgisini ve iletim istatistiklerini izlemek için kullanılır. Bu protokollerin her ikisi beraber kullanıldığı zaman RTP portunun bir çift sayıya denk gelmesi gerekir. RTCP portu ise o oturuma ait RTP portundan sonraki elverişli olan ilk tek port numarasıdır. RTP ve RTCP genellikle 1024-65535 arası portları kullanır.

Geçmiş

RTSP RealNetworks, Netscape^[1] ve Columbia Üniversitesi tarafından geliştirilmiştir.^[2] İ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.^[3]^[4] İ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ı..^[5]^[6] RTSP için Önerilen Standart, 1998'de RFC 2326 olarak yayınlandı.^[7] 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.^[8]

Genel Tanıtım

RTP IETF standartları organizasyonunun Audio/Video Transport çalışma grubu tarafından geliştirildi. RTP H.323 ve RTSP gibi diğer protokoller ile beraber kullanılır. RTP standardı RTP ve Real-time Transport Control Protocol (RTCP) yi bir protokol çiftini tanımlar. RTP multimedia veri transferi için kullanılır ve RTCP periyodik olarak QoS parametrelerini kontrol bilgilerini yollamak için kullanılır.

RTP çoklu ortam verilerinin gerçek-zamanlı(real-time), uçtan uca ( end-to-end) transferi için tasarlanmıştır. Protokol bir IP network üzerindeki veri iletiminde verilerdeki sıra bozukluğunu tespit eder ve jitter (network üzerinde paketlerin geliş süresindeki, düzenindeki değişiklik) kompanzasyonu için kolaylık sağlar. RTP multicast servisler üzerinden birden çok hedefe veri transferini destekler. RTP IP ağlarında ses/video iletiminde öncelikli standart olarak kabul edilir.

Gerçek zamanlı çoklu ortam streaming uygulamaları zamanında bilgileri teslim etmeyi gerektirir ve bu amacı gerçekleştirmek için bazı kaybolan paketleri tolere edebilmelidir. Örneğin audio (ses) uygulamasında kaybolan bir paket ikinci bir paketinin kaybolmasına neden olabilir. TCP RTP için standart haline gelmiş olmasına rağmen bağlantı kurulumundaki ve hata düzeltmedeki doğal gecikmelerden dolayı sık kullanılmamaktadır. RTP yürütme işlemlerinin çoğu UDP üzerine temellendirilir. Diğer taşıma protokolleri daha henüz yaygın olarak kullanılmasalar da özellikle çoklu ortam oturumları (sessions) için tasarlanan SCTP ve DCCP dir.

Protokol Bileşenleri

RTP iki alt protokolü tanımlar:

Veri Transfer Protokolü: gerçek zamanlı çoklu ortam verisinin transferiyle ilgilenir. Bu protokol tarafından sağlanan bilgi senkronizasyon için tarih bilgisi, kaybolan paketlerin denetimi için sıra numarası ve verinin kodlanmış formatını gösteren payload formatını içerir.
Gerçek Zamanlı Kontrol Protokolü: Servis önceliği (QoS) ile ilgili geribildirimler ve ortam streamleri arasında senkronisazyonu belirtmek için kullanılır.

Oturumlar

Veri iletimi esnasında iki uç arası bir RTP oturumu kurulur. Bu oturum IP adresleri ve RTP ve RTCP ye ait portlardan oluşur. Bu oturum içerisindeki cihazlar veri alıp gönderebilirler. Her bir medya türü için cihazlar arası ayrı bir oturum oluşturulur. Bir RTP oturumu her ortam streami için kurulur. Böylelikle oturum içerisindeki kişilerin hangi medya tipinden veri almak istemelerine imkân sağlanmış olur. Örneğin bir kullanıcı yayınlanan bir filmin sadece sesini almak isteyebilir. Bu durumda alıcının video yayınını engellemesi yeterli olacaktır.

Profiller ve Payload Formatları

RTP nin formatında dikkat edilecek hususlardan biri birçok formatı desteklemesidir (H.264, MPEG-4, MJPEG, MPEG, gibi). RTP, standartların yeniden düzenlenmesinin dışında yeni formatların eklenmesine izin verir. RTP protokolünün yapısı Application Level Framing(ALF) ye dayanmaktadır. RTP bu yapsısı itibarı ile birden çok çokluortam formatında yayın yapıp alabilmektedir. RTP de belli bir formatta veri transferi için gerekli bilgiler RTP başlığının içerisinde değil RTP Payload bilgisi ve Profil bilgisi içerisinde yer alır. RTP her bir uygulama için bir profil ve buna bağlı payload girdilerini belirler. Bu da birçok format ile uyumlu çalışmasına imkân sağlar.

RTP de profil bilgisi payload veriyi kodlamak için kullanılan kodlayıcıları (codec) tanımlar ve profil başlığındaki "Payload TYpe" alanındaki payload format kodları için onların eşleşmelerini tanımlar. Her profil birkaç payload format belirtimleriyle beraberdir. Ses Payload formatlarından bazıları G.711, G.723, G.726, G.729, GSM, QCELP, MP3 içerir. Ve video Payload formatlarından bazıları H.261, H.263, H.264, MPEG yi içerir.

Paket Başlığı

bit offset	0-1	2	3	4-7	8	9-15	16-31
0	Ver.	P	X	CC	M	PT	Sequence Number
32	Timestamp
64	SSRC identifier
96	CSRC identifiers (optional) ...

RTP başlığı en az 12 byte boyutundadır. Başlıktan sonra seçimli başlık uzantıları bulunabilir. Başlık alanları aşağıdaki gibidir.

Ver.: (2 bit) Protokolün versiyonunu işaret eder. Şu andaki versiyon 2 dir.
P (Padding): (1 bit) Eğer RTP paketinin sonunda ekstra doldurma (padding) bytelar varsa bunları işaret etmek için kullanılır. Bir padding belirli bir boyutun bir bloğunu,bir kısmını doldurmak için kullanılabilir.
X (Extension): (1 bit) Payload veri ve standart başlık kısmı arasındaki bir uzantı başlığının varlığını işaret eder.
CC (CSRC Count): (4 bit) sabit başlığı takip eden CSRC tanımlayıcılarının sayısını içerir.
M (Marker): (1 bit) Bir profil tarafından tanımlanır ve uygulama seviyesinde kullanılır. Eğer ayarlanırsa uygulama için o andaki verinin uygulamayla ilgili bazı özel durumlara sahip olduğunu belirtir.
PT (Payload Type): (7 bit) Payload formatını gösterir. Ve uygulama tarafından onun yorumlanmasına karar verilir. Bir RTP profili tarafından belirtilir. Örneğin minimal kontrol ile ses ve video konferansları.
Sequence Number: (16 bit) Sıra numarası RTP başlığında paket kaybını belirlemeye yarayan ve aynı tarih bilgisi değerine sahip paketlerin sıralanmasını sağlar. Ve başlangıç değeri rastgele olarak belirlenir.
Timestamp: (32 bit) Uygun aralıklarla kabul edilen örnekleri, kayıtları yeniden göstermek için alıcı uygulamaya imkân tanıması amacıyla kullanılır. Birkaç ortam streamleri mevcut ise, timestamp lar her stream de bağımsızdır ve ortam senkronizasyonu için güvenilir olmayabilir. Senkronizasyona ve jitter hesaplamalarına izin vermek için zaman içinde tekdüze ve artan bir şekilde artan zaman bilgisinden meydana gelir.
SSRC: (32 bit) Senkronizasyon kaynak tanımlayıcıları tek bir şekilde bir streamin kaynağını tanımlar. aynı RTP oturumu içindeki senkronizasyon kaynağı tek ve eşsiz olmalıdır. Bu tanımlayıcı rastgele seçilir.
CSRC: 32 bitlik yardımcı kaynaktır. Yardımcı kaynak idleri birçok kaynaktan oluşturulan bir stream için yardımcı kaynakları numaralandırır.
Uzantı Başlığı:(seçimli) İlk 32 bitlik alan özel bir profil tanımlayıcısı ve uzantı başlığının 32 bitinin dışında 32 bitlik birimlerde (EHL=uzantı başlık uzunluğu) uzantının uzunluğunu belirten 16 bitlik bir uzunluk tanımlayıcısın içerir.

RTP Tabanlı Sistemler

Tam bit network tabanlı sistem RTP ile beraber diğer protokoller ve standartları da kapsayacak. SIP, RTSP, H.225 ve H.263 e benzer protokoller oturum başlatılması, kontrol edilmesi ve sonlandırılması için kullanılır. H.263, H.264, MPEG gibi standartlar da RTP profili üzerinden tanımlanan payload veriyi kodlamak için kullanılır.

RTP ister connection-oriented ister connectionless olsun bağlantının türünden bağımsız olarak çalışır. Herhangi bir adres formatına bağımlılığı yoktur. Sadece çerçeveleme(framing) ve segmentasyon işlemlerinin alt katmandaki protokoller tarafından halledilmesini bekler. RTP herhangi bir şekilde reliability (güvenilirlik) garantisi vermez. RTP paket başlığında içerdiği bilgilerle hata kontrolü yapılmasını sağlar. RTP protokolü sanki uygulamanın bir bileşeniymiş gibi çalışır. RTP adının gerçek zamanlı iletişim protokolü olmasına rağmen (pratikte olamayacağı gibi) gerçek zamanlı iletişim sağlamaz. RTP gerçek zamanlı uygulama içeriğini taşınmasını sağlar.

Protokol Direktifleri

Bazı yönlerden HTTP'ye benzer olsa da RTSP , multimedya oynatmayı kontrol etmede yararlı olan kontrol sıralarını tanımlar. HTTP durumsuzken , RTSP'nin bir durumu vardır; eşzamanlı oturumları izlemek için gerektiğinde bir tanımlayıcı kullanılır. HTTP gibi, RTSP de uçtan uca bir bağlantıyı sürdürmek için TCP kullanır ve RTSP kontrol mesajlarının çoğu istemci tarafından sunucuya gönderilirken, bazı komutlar diğer yönde (yani sunucudan istemciye) hareket eder.

Burada sunulan temel RTSP istekleridir. SEÇENEKLER isteği gibi bazı tipik HTTP istekleri de mevcuttur. Hem TCP hem de UDP için varsayılan taşıma katmanı bağlantı noktası numarası 554'tür.UDP nadiren kontrol istekleri için kullanılır.

SEÇENEKLER

SEÇENEKLER isteği, sunucunun kabul edeceği istek türlerini döndürür.

C->S:  OPTIONS rtsp://example.com/media.mp4 RTSP/1.0
       CSeq: 1
       Require: implicit-play
       Proxy-Require: gzipped-messages

S->C:  RTSP/1.0 200 OK
       CSeq: 1
       Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

AÇIKLAMA

AÇIKLAMA isteği, bir RTSP URL'si ve işlenebilecek yanıt verisi türünü içerir. Bu yanıt, genellikle Oturum Açıklama Protokolü (SDP) biçiminde olan sunum açıklamasını içerir . Sunum açıklaması, diğer şeylerin yanı sıra, birleştirilmiş URL ile kontrol edilen medya akışlarını listeler. Tipik durumda, ses ve video akışları için birer medya akışı vardır. Medya akışı URL'leri ya doğrudan SDP kontrol alanlarından elde edilir ya da SDP kontrol alanı toplu URL'ye eklenerek elde edilir.

C->S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 2

S->C: RTSP/1.0 200 OK
      CSeq: 2
      Content-Base: rtsp://example.com/media.mp4
      Content-Type: application/sdp
      Content-Length: 460

      m=video 0 RTP/AVP 96
      a=control:streamid=0
      a=range:npt=0-7.741000
      a=length:npt=7.741000
      a=rtpmap:96 MP4V-ES/5544
      a=mimetype:string;"video/MP4V-ES"
      a=AvgBitRate:integer;304018
      a=StreamName:string;"hinted video track"
      m=audio 0 RTP/AVP 97
      a=control:streamid=1
      a=range:npt=0-7.712000
      a=length:npt=7.712000
      a=rtpmap:97 mpeg4-generic/32000/2
      a=mimetype:string;"audio/mpeg4-generic"
      a=AvgBitRate:integer;65790
      a=StreamName:string;"hinted audio track"

KURULUM

KURULUM isteği, tek bir ortam akışının nasıl taşınması gerektiğini belirtir. Bu, bir OYNAT isteği gönderilmeden önce yapılmalıdır. İstek, medya akışı URL'sini ve bir taşıma belirticisini içerir. Bu belirtici tipik olarak RTP verilerini (ses veya video) almak için bir yerel bağlantı noktası ve RTCP verilerini (meta bilgileri) almak için başka bir bağlantı noktası içerir. Sunucu yanıtı genellikle seçilen parametreleri onaylar ve sunucunun seçtiği portlar gibi eksik kısımları doldurur. Toplu oynatma isteği gönderilmeden önce her ortam akışı KURULUM kullanılarak yapılandırılmalıdır.

C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8000-8001

S->C: RTSP/1.0 200 OK
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD
      Session: 12345678



C->S: SETUP rtsp://example.com/media.mp4/streamid=1 RTSP/1.0
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8002-8003
      Session: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8002-8003;server_port=9002-9003;ssrc=1234ABCD
      Session: 12345678

OYNA

Bir OYNAT isteği, medya akışlarından birinin veya tümünün oynatılmasına neden olur. Oynatma istekleri, birden çok OYNAT isteği gönderilerek istiflenebilir. URL, toplu URL (tüm medya akışlarını oynatmak için) veya tek bir medya akışı URL'si (yalnızca o akışı oynatmak için) olabilir. Bir aralık belirtilebilir. Aralık belirtilmezse akış baştan oynatılır ve sonuna kadar oynatılır veya akış duraklatılırsa duraklatıldığı noktadan devam ettirilir.

C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 4
      Range: npt=5-20
      Session: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 4
      Session: 12345678
      RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012

DURAKLAT

DURAKLATMA isteği, medya akışlarından birini veya tümünü geçici olarak durdurur, böylece daha sonra bir OYNAT isteğiyle devam ettirilebilir. İstek, bir toplu veya medya akışı URL'si içeriyor. PAUSE isteğindeki bir aralık parametresi, ne zaman duraklatılacağını belirtir. Aralık parametresi atlandığında, duraklama hemen ve süresiz olarak gerçekleşir.

C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 5
      Session: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 5
      Session: 12345678

KAYDET

Bu yöntem, sunum açıklamasına göre bir dizi ortam verisinin kaydedilmesini başlatır. Zaman damgası, başlangıç ve bitiş zamanını (UTC) yansıtır. Herhangi bir zaman aralığı belirtilmemişse, sunum açıklamasında verilen başlangıç veya bitiş zamanını kullanın. Oturum zaten başladıysa, kayda hemen başlayın. Sunucu, kaydedilen verilerin istek URI'si altında mı yoksa başka bir URI'de mi depolanacağına karar verir. Sunucu istek URI'sini kullanmıyorsa, yanıt 201 olmalı ve isteğin durumlarını açıklayan ve yeni kaynağa atıfta bulunan bir varlık ve bir Konum başlığı içermelidir.

C->S: RECORD rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 6
      Session: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 6
      Session: 12345678

DUYURU

Duyuru yöntemi iki amaca hizmet eder:

Duyuru, istemciden sunucuya gönderildiğinde, istek URL'si tarafından tanımlanan bir sunumun veya medya nesnesinin açıklamasını bir sunucuya gönderir. Duyuru, 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.


C->S: ANNOUNCE rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 7
      Date: 23 Jan 1997 15:35:06 GMT
      Session: 12345678
      Content-Type: application/sdp
      Content-Length: 332

      v=0
      o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4
      s=SDP Seminar
      i=A Seminar on the session description protocol
      u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
      [email protected] (Mark Handley)
      c=IN IP4 224.2.17.12/127
      t=2873397496 2873404696
      a=recvonly
      m=audio 3456 RTP/AVP 0
      m=video 2232 RTP/AVP 31

S->C: RTSP/1.0 200 OK
      CSeq: 7

TEARDOWN

Oturumu sonlandırmak için TEARDOWN isteği kullanılır. Tüm medya akışlarını durdurur ve sunucudaki oturumla ilgili tüm verileri serbest bırakır.

C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 8
      Oturum: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 8

GET_PARAMETER

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.

S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 9
      Content-Type: text/parameters
      Session: 12345678
      Content-Length: 15

      packets_received
      jitter

C->S: RTSP/1.0 200 OK
      CSeq: 9
      Content-Length: 46
      Content-Type: text/parameters

      packets_received: 10
      jitter: 0.3838

SET_PARAMETER

Bu yöntem, URI tarafından belirtilen bir sunum veya akış için bir parametrenin değerini ayarlamayı talep eder.

C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 10
      Content-length: 20
      Content-type: text/parameters

      barparam: barstuff

S->C: RTSP/1.0 451 Invalid Parameter
      CSeq: 10
      Content-length: 10
      Content-type: text/parameters

      barparam

YÖNLENDİRME

REDIRECT 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.

S->C: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 11
      Location: rtsp://bigserver.com:8001
      Range: clock=19960213T143205Z-

Katıştırılmış (Araya Eklenmiş) İkili Veri

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.

C->S: SETUP rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 3
      Transport: RTP/AVP/TCP;interleaved=0-1

S->C: RTSP/1.0 200 OK
      CSeq: 3
      Date: 05 Jun 1997 18:57:18 GMT
      Transport: RTP/AVP/TCP;interleaved=0-1
      Session: 12345678

C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 4
      Session: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 4
      Session: 12345678
      Date: 05 Jun 1997 18:59:15 GMT
      RTP-Info: url=rtsp://example.com/media.mp4;seq=232433;rtptime=972948234

S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C: $\001{2 byte length}{"length" bytes  RTCP packet}

Dış bağlantılar

Kaynaklar

^ InfoWorld Media Group, Inc. (2 March 1998). InfoWorld. InfoWorld Media Group, Inc. s. 18. ISSN 0199-6649.
^ Rafael Osso (1999). Handbook of Emerging Communications Technologies: The Next Decade. CRC Press. s. 42. ISBN 978-1-4200-4962-6.
^ Rao, Anup; Lanphier, Rob. "Real Time Streaming Protocol (RTSP)". Ietf Datatracker (İngilizce). Erişim tarihi: 2021-02-23.
^ "RTSP prime" Henning Schulzrinne, Columbia University(http://www.cs.columbia.edu/~hgs/papers/Schu9612_RTSP.ps) December 1996
^ Schulzrinne, Henning; Rao, Anup; Lanphier, Rob (1997-02-24). "Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-01.txt)". Ietf Datatracker (İngilizce). Erişim tarihi: 2021-02-23.
^ Schulzrinne, Henning; Rao, Anup; Lanphier, Rob (1998-01-15). "Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-08.txt)". Ietf Datatracker (İngilizce). Erişim tarihi: 2021-02-23.
^ RFC 2326, Real Time Streaming Protocol (RTSP), IETF, 1998
^ Schulzrinne, Henning; Rao, Anup; Lanphier, Rob; Westerlund, Magnus; Stiemerling, Martin (December 2016). Stiemerling, M (Ed.). "Real-Time Streaming Protocol Version 2.0". tools.ietf.org (İngilizce). doi:10.17487/RFC7826. Erişim tarihi: 2021-02-23.

[Inc.1998-1] InfoWorld Media Group, Inc. (2 March 1998). InfoWorld. InfoWorld Media Group, Inc. s. 18. ISSN 0199-6649.

[Osso1999-2] Rafael Osso (1999). Handbook of Emerging Communications Technologies: The Next Decade. CRC Press. s. 42. ISBN 978-1-4200-4962-6.

[3] Rao, Anup; Lanphier, Rob. "Real Time Streaming Protocol (RTSP)". Ietf Datatracker (İngilizce). Erişim tarihi: 2021-02-23.

[4] "RTSP prime" Henning Schulzrinne, Columbia University(http://www.cs.columbia.edu/~hgs/papers/Schu9612_RTSP.ps) December 1996

[5] Schulzrinne, Henning; Rao, Anup; Lanphier, Rob (1997-02-24). "Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-01.txt)". Ietf Datatracker (İngilizce). Erişim tarihi: 2021-02-23.

[6] Schulzrinne, Henning; Rao, Anup; Lanphier, Rob (1998-01-15). "Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-08.txt)". Ietf Datatracker (İngilizce). Erişim tarihi: 2021-02-23.

[:0-7] RFC 2326, Real Time Streaming Protocol (RTSP), IETF, 1998

[8] Schulzrinne, Henning; Rao, Anup; Lanphier, Rob; Westerlund, Magnus; Stiemerling, Martin (December 2016). Stiemerling, M (Ed.). "Real-Time Streaming Protocol Version 2.0". tools.ietf.org (İngilizce). doi:10.17487/RFC7826. Erişim tarihi: 2021-02-23.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]