一篇文章讀懂流媒體傳輸協議RTP、RTCP、RTSP、SRTP&SRTCP
概要
一句話：RTSP發起/終結流媒體、RTP傳輸流媒體資料 、RTCP對RTP進行控制，同步。
因為CTC標準裡沒有對RTCP進行要求，因此在標準RTSP的程式碼中沒有看到相關的部分。而在私有RTSP的程式碼中，有關控制、同步等，是在RTP Header中做擴充套件定義實現的。另外，RFC3550(datatracker)可以看作是RFC1889的升級文件，只看RFC3550/RFC3551即可。
RTP
RTP簡介
RTP(Real Time Transport Protocol)是針對Internet上多媒體資料流的一個傳輸協議, 由IETF(Internet工程任務組)作為RFC1889
RTP工作機制
多媒體資料傳輸的一個尖銳的問題就是不可預料資料到達時間。但是流媒體的傳輸是需要資料的適時的到達用以播放和回放。rtp協議就是提供了時間標籤,序列號以及其它的結構用於控制適時資料的流放。在流的概念中”時間標籤”是最重要的資訊。傳送端依照即時的取樣在資料包裡隱蔽的設定了時間標籤。在接受端收到資料包後,就依照時間標籤按照正確的速率恢復成原始的適時的資料。不同的媒體格式調時屬性是不一樣的。但是rtp本身並不負責同步，rtp只是傳輸層協議，為了簡化運輸層處理，提高該層的效率。將部分運輸層協議功能（比如流量控制）上移到應用層完成。同步就是屬於應用層協議完成的。它沒有運輸層協議的完整功能，不提供任何機制來保證實時地傳輸資料，不支援資源預留，也不保證服務質量。rtp報文甚至不包括長度和報文邊界的描述。同時rtp協議的資料報文和控制報文的使用相鄰的不同埠，這樣大大提高了協議的靈活性和處理的簡單性。
rtp協議和udp二者共同完成運輸層協議功能。udp協議只是傳輸資料包，不管資料包傳輸的時間順序。 rtp的協議資料單元是用udp分組來承載的。在承載rtp資料包的時候，有時候一幀資料被分割成幾個包具有相同的時間標籤，則可以知道時間標籤並不是必須的。而udp的多路複用讓rtp協議利用支援顯式的多點投遞，可以滿足多媒體會話的需求。
rtp協議雖然是傳輸層協議但是它沒有作為osi體系結構中單獨的一層來實現。rtp協議通常根據一個具體的應用來提供服務，rtp只提供協議框架，開發者可以根據應用的具體要求對協議進行充分的擴充套件。
RTP協議報文結構
如下圖所示
開始12個八進位制出現在每個RTP包中，而CSRC標識列表僅出現在混合器插入時。各段含義如下：
①版本（V）
version (V): 2 bits 2位，標識RTP版本,協議初始版本為0，RFC3550中規定的版本號為2。。
②填充標識（P）
padding (P): 1 bit 1位，如設定填充位，在包末尾包含了額外的附加資訊，它不屬於有效載荷。附加資訊的最後一個位元組表示額外附加資訊的長度（包含該位元組本身）。該欄位之所以存在是因為某些加密演算法需要固定大小的填充字，或為在底層協議資料單元中攜帶幾個RTP包。
③擴充套件（X）
extension (X): 1 bit 1位，如果該位被設定，則在固定的頭部後存在一個擴充套件頭部，格式定義在RFC3550 5.3.1節。
④CSRC計數（CC）
CSRC count (CC): 4 bits 4位，CSRC計數包括緊接在固定頭後標識CSRC個數。
⑤標記（M）
marker (M): 1 bit 1位，標記解釋由設定定義，目的在於允許重要事件在包流中標記出來。設定可定義其他標示位，或通過改變位數量來指定沒有標記位，該位的功能依賴於profile的定義。profile可以改變該位的長度，但是要保持marker和payload type總長度不變（一共是8 bit）。。
⑥載荷型別（PT）
payload type (PT): 7 bits 7位，記錄後面資料使用哪種 Codec ， receiver 端找出相應的 decoder 解碼出來，該位標記著RTP packet所攜帶資訊的型別，標準型別列出在RFC3551中。如果接收方不能識別該型別，必須忽略該packet。
⑦系列號
sequence number:16 bits 16位，系列號隨每個RTP資料包傳送後而增加1，接收方可以根據該序列號重新排列資料包順序，或者探測包損失。系列號初值是隨機的，使對加密的文字攻擊更加困難。
⑧時標
timestamp: 32 bits 32位，時標反映RTP資料包中第一個八進位制數的取樣時刻，取樣時刻必須從單調、線性增加的時鐘匯出，以允許同步與抖動計算。時標可以讓receiver端知道在正確的時間將資料播放出來。
由上圖可知，如果只有系列號，並不能完整按照順序的將data播放出來，因為如果data中間有一段是沒有資料的，只有系列號的話會造成錯誤，需搭配上讓它知道在哪個時間將data正確播放出來，如此我們才能播放出正確無誤的資訊。
⑨SSRC
SSRC: 32 bits 32位，SSRC段標識同步源。此標識不是隨機選擇的，目的在於使同一RTP包連線中沒有兩個同步源有相同的SSRC標識，也就是在一個RTP Session其間每個資料流都應該有一個不同的SSRC。儘管多個源選擇同一個標識的概率很低，所有RTP實現都必須探測並解決衝突。如源改變源傳輸地址，也必須選擇一個新SSRC標識以避免插入成環行源。
⑩CSRC列表
CSRC list: 0 to 15 items bits0到15項，每項32位。CSRC列表表示包內的對載荷起作用的源。標識數量由CC段給出。如超出15個作用源，也僅標識15個。CSRC標識由混合器插入，採用作用源的SSRC標識。只有存在Mixer的時候才有效。如一個將多聲道的語音流合併成一個單聲道的語音流，在這裡就列出原來每個聲道的SSRC。
從RTP資料報的格式不難看出，它包含了傳輸媒體的型別、格式、序列號、時間戳以及是否有附加資料等資訊，這些都為實時的流媒體傳輸提供了相應的基礎。RTP協議的目的是提供實時資料（如互動式的音訊和視訊）的端到端傳輸服務，因此在RTP中沒有連線的概念，它可以建立在底層的面向連線或面向非連線的傳輸協議之上；RTP也不依賴於特別的網路地址格式，而僅僅只需要底層傳輸協議支援組幀（Framing）和分段（Segmentation）就足夠了；另外RTP本身還不提供任何可靠性機制，這些都要由傳輸協議或者應用程式自己來保證。在典型的應用場合下，RTP一般是在傳輸協議之上作為應用程式的一部分加以實現的 ，如下圖所示：
RTCP
RTCP簡介
RTCP(Real Time Contorl Protocol)負責管理傳輸質量在當前應用程序之間交換控制資訊。在RTP會話期間，各參與者週期性地傳送RTCP包，包中含有已傳送的資料包的數量、丟失的資料包的數量等統計資料。因此，伺服器可以利用這些資訊動態地改變傳輸速率，甚至改變有效載荷型別。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，故特別適合傳送網上的實時資料。
RTCP工作機制
當應用程式開始一個rtp會話時將使用兩個埠：一個給rtp，一個給rtcp。rtp本身並不能為按順序傳送資料包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠rtcp提供這些服務。在rtp的會話之間週期的發放一些rtcp包以用來傳監聽服務質量和交換會話使用者資訊等功能。rtcp包中含有已傳送的資料包的數量、丟失的資料包的數量等統計資料。因此，伺服器可以利用這些資訊動態地改變傳輸速率，甚至改變有效載荷型別。rtp和rtcp配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時資料。根據使用者間的資料傳輸反饋資訊，可以制定流量控制的策略，而會話使用者資訊的互動，可以制定會話控制的策略。
RTCP協議將控制包週期傳送給所有連線者，應用與資料包相同的分佈機制。低層協議提供資料與控制包的複用，如使用單獨的UDP埠號。RTCP執行下列四大功能：
主要是提供資料釋出的質量反饋。是作為RTP傳輸協議的一部分，與其他傳輸協議的流和阻塞控制有關。反饋對自適應編碼控制直接起作用，但IP組播經驗表明，從傳送者收到反饋對診斷髮送錯誤是致關重要的。給所有參加者傳送接收反饋報告允許問題觀察者估計那些問題是區域性的，還是全域性的。諸如IP組播等釋出機制使網路服務提供商類團體可能接收反饋資訊，充當第三方監控者來診斷網路問題。反饋功能由RTCP傳送者和接收者報告執行。
RTCP帶有稱作規範名字（CNAME）的RTP源持久傳輸層標識。如發現衝突，或程式重新啟動，既然SSRC標識可改變，接收者需要CNAME跟蹤參加者。接收者也需要CNAME 與相關RTP連線中給定的幾個資料流聯絡
前兩種功能要求所有參加者傳送RTCP包，因此，為了RTP擴充套件到大規模數量，速率必須受到控制。讓每個參加者給其它參加者傳送控制包，就大獨立觀察參加者數量。該數量用語計算包傳送的速率。
第四個可選功能是傳送最小連線控制資訊，如參加者辨識。最可能用在"鬆散控制"連線，那裡參加者自由進入或離開，沒有成員控制或引數協調，RTCP充當通往所有參加者的方便通道，但不必支援應用的所有控制通訊要求。在IP組播場合應用RTP時，前3個功能是必須的，推薦用於所有情形。RTP應用設計人員必須避免使用僅在單播模式下工作的機制，那將導致無法擴充套件規模。
RTCP資料報
在RTCP通訊控制中，RTCP協議的功能是通過不同的RTCP資料報來實現的，主要有如下幾種型別：
①SR:傳送端報告，所謂傳送端是指發出RTP資料報的應用程式或者終端，傳送端同時也可以是接收端。
②RR:接收端報告，所謂接收端是指僅接收但不傳送RTP資料報的應用程式或者終端。
③SDES:源描述，主要功能是作為會話成員有關標識資訊的載體，如使用者名稱、郵件地址、電話號碼等，此外還具有向會話成員傳達會話控制資訊的功能。
④BYE:通知離開，主要功能是指示某一個或者幾個源不再有效，即通知會話中的其他成員自己將退出會話。
⑤APP:由應用程式自己定義，解決了RTCP的擴充套件性問題，並且為協議的實現者提供了很大的靈活性。
SDES: 源描述RTCP包
SDES 包為三層結構，由頭與資料塊組成，資料塊可以沒有，也可有多個，組成項描述塊所表明的源。項描述如下：
版本（V）、填充（P）、長度： 如SR包中所描述。
包型別（PT）： 8位，包含常數202，識別RTCP SDES包。
源計數（SC）： 5位，包含在SDES包中的SSRC/CSRC塊數量，零值有效，但沒有意義。
源描述項內容如下：
CNAME: 規範終端標識SDES項 CNAME標識屬性如下：
如發生衝突或重啟程式，由於隨機分配的SSRC標識可能發生變化，需要CNAME項提供從SSRC標識到仍為常量的源標識的繫結。 象SSRC標識，CNAME標識在RTP連線的所有參加者中應是唯一的。 為了提供一套相關RTP連線中某個參加者所採用的跨多媒體工具間的繫結，CNAME應固定為那個參加者。 為方便第三方監控，CNAME應適合程式或人員定位源。
NAME：使用者名稱稱SDES項
BYE：斷開RTCP包
如混合器接收到一個BYE包，混合器轉發BYE包，而不改變SSRC/CSRC 標識。如混合器關閉，它也應該發出一個BYE包，列出它所處理的所有源，而不只是自己的SSRC標識。作為可選項，BYE包可包括一個8位八進位制計數，後跟很多八進位制文字，表示離開原因，如："camera malfunction"或"RTP loop detected"。字串具有同樣的編碼，如在SDES 中所描述的。如字串填充包至下32位邊界，字串就不以空結尾；否則，BYE包以空八進位制填充。
APP：定義應用的RTCP包
APP包用於開發新應用和新特徵的實驗，不要求註冊包型別值。帶有不可識別名稱的APP包應被忽略掉。測試後，如確定應用廣泛，推薦重新定義每個APP包，而不用向IANA註冊子型別和名稱段。
RTSP
RTSP簡介
是由Real Networks和Netscape共同提出的。該協議定義了一對多應用程式如何有效地通過IP網路傳送多媒體資料。RTSP提供了一個可擴充套件框架，使實時資料，如音訊與視訊的受控、點播成為可能。資料來源包括現場資料與儲存在剪輯中的資料。該協議目的在於控制多個數據傳送連線，為選擇傳送通道，如UDP、多播UDP與TCP提供途徑，併為選擇基於RTP上傳送機制提供方法。RTSP參考文件 RFC2336
RTSP（Real Time Streaming Protocol）是用來控制聲音或影像的多媒體串流協議，並允許同時多個串流需求控制，傳輸時所用的網路通訊協定並不在其定義的範圍內，伺服器端可以自行選擇使用TCP或UDP來傳送串流內容，它的語法和運作跟HTTP 1.1類似，但並不特別強調時間同步，所以比較能容忍網路延遲。而前面提到的允許同時多個串流需求控制（Multicast），除了可以降低伺服器端的網路用量，更進而支援多方視訊會議（Video Conference）。 因為與HTTP1.1的運作方式相似，所以代理伺服器《Proxy》的快取功能《Cache》也同樣適用於RTSP，並因RTSP具有重新導向功能，可視實際負載情況來轉換提供服務的伺服器，以避免過大的負載集中於同一伺服器而造成延遲。
RTSP協 議以客戶伺服器方式工作，它是一個多媒體播放控制協議，用來使使用者在播放從因特網下載的實時資料（音訊和視訊流）時能夠進行控制，如：暫停/繼 續、後退、前進等。因此 RTSP 又稱為“因特網錄影機遙控協議”。
要實現 RTSP 的控制功能，不僅要有協議，而且要有專門的媒體播放器(media player)和 媒體伺服器(media server)。媒體伺服器與媒體播放器的關係是伺服器與客戶的關係。媒體伺服器與普通的全球資訊網伺服器的最大區別就是媒體伺服器支援流式音訊和視訊的傳送，因而在客戶端的媒體播放器可以邊下載邊播放（需要先快取一小段時間的節 目）。但從普通全球資訊網伺服器下載多媒體節目時，是先將整個檔案下載完畢，然後再進行播放。RTSP 僅僅是使媒體播放器能控制多媒體流的傳送。因此，RTSP 又稱為帶外協議，而多媒體流是使用 RTP 在帶內傳送的。如圖所示
RTSP協議特點
● 可擴充套件性：新方法和引數很容易加入RTSP。
● 易解析：RTSP可由標準 HTTP或MIME解析器解析。
● 安全：RTSP使用網頁安全機制。
● 獨立於傳輸：RTSP傳輸通道，可使用不可靠資料包協議（UDP）或可靠資料包協議（RDP），如要實現應用級可靠，可使用諸如TCP的可靠流協議。
● 記錄裝置控制：協議可控制記錄和回放裝置。
● 適合專業應用：通過SMPTE 時標，RTSP支援幀級精度，允許遠端數字編輯。
● 演示描述中立：協議未強加特殊演示或元檔案，可傳送所用格式型別；然而，演示描述至少需包含一個RTSP URI。
● 代理與防火牆友好：協議可由應用和傳輸層防火牆處理。防火牆需要理解SETUP方法，為UDP媒體流開啟一個“缺口”。
● 適當的伺服器控制：如使用者啟動一個流，則也可以停止一個流。
● 傳輸協調：實際處理連續媒體流前，使用者可協調傳輸方法。
● 效能協調：如基本特徵無效，則必須有一些清理機制讓使用者決定那種方法不生效。這允許使用者提出適合自己的介面。
RTSP與HTTP
RTSP在功能上與HTTP有重疊，最明顯的交叉是在流媒體內容的釋出上——----大多是通過網頁進行的。目前的協議規範同時允許網頁伺服器和流媒體伺服器支援RTSP實現。例如，演示描述可通過HTTP或RTSP獲取，這樣減少了基於瀏覽器情況下的往返傳遞時間，同時也支援獨立的RTSP 伺服器與不依賴HTTP的客戶端通訊。
但是，RTSP與HTTP 的本質差別在於以下五個方面
● RTSP和HTTP是兩個不同的協議，它們採用不同的方法和協議標誌符。
● RTSP協議的資料傳送不佔用協議頻寬，並且以不同的協議傳送。
● HTTP是一個不對稱協議，客戶端發出請求，伺服器應答。在RTSP中，客戶端和伺服器都可發出請求，且請求是有狀態的。
● HTTP是一個無狀態協議，而RTSP在任何情況下，必須保持一定狀態，以便在請求確認後的很長時間內，仍可設定引數，控制媒體流。
● RTSP使用ISO 10646（UTF-8）定義，而不使用ISO 8859-1定義，保持與當前的HTML一致。
雖然大多數實時媒體採用RTP作為傳輸協議，但RTSP並不繫結RTP。重用HTTP的功能至少在兩個方面有好處:安全和代理。由於要求非常接近，因此在快取、代理和授權上採用HTTP功能是有價值的。
HTTP與RTSP傳輸的差別。概括的講，RTSP被許多公司防火牆拒絕，而HTTP可以作為一個普通的檔案通過；RTSP適合於大資料量、高可用性的流，如直播事件、長事件或大型檔案；HTTP更適合於較小的資料傳輸和互動；當終端使用者正在觀看時，RTSP允許使用者在伺服器有效的回放媒體，HTTP更象下載一段媒體並在客戶機上播放。從終端使用者觀點來看，RTSP看起來像是檔案從中心位置播放，有點象廣播，而HTTP感覺更象時從視訊庫中取視訊，並在家裡的機器上播放。從服務質量的觀點上看，對於流，RTSP有更好的體驗，RTSP提供類似於VCR的媒體控制，如暫停、快進、倒退和絕對定位。使用HTTP傳輸，只能在整個流下載完成後，播放器軟體再模擬該過程。雖然，RTSP能夠使用TCP或UDP，但是RTSP控制經常與RTP聯合使用，以最好的服務質量傳送實際的媒體資料。
RTSP 報文結構
RTSP有兩類報文：請求報文和響應報文。
請求報文是指從客戶向伺服器傳送請求報文，響應報文是指從伺服器到客戶的回答。由於RTSP是面向正文的(text-oriented)，因此在報文中的每一個欄位都是一些 ASCII 碼串，因而每個欄位的長度都是不確定的。RTSP報文由三部分組成，即開始行、首部行和實體主體。在請求報文中，開始行就是請求行，RTSP請求報文的結構如圖所示。
RTSP請求報文的方法包括：OPTIONS（獲得伺服器提供的可用方法）、DESCRIBE（得到會話描述資訊）、SETUP（客戶端提醒伺服器建立會話，並確定傳輸模式）、TEARDOWN（客戶端發起關閉請求）、ANNOUNCE(更新會話描述）、PLAY（客戶端傳送播放請求）、PAUSE（臨時停止流，而不釋放伺服器資源）、GET_PARAMETER（取得流控制引數，可能某些伺服器不支援）和SET_PARAMETER（設定流控制引數，可能某些伺服器不支援）。響應報文的開始行是狀態行，RTSP響應報文的結構如圖所示。
RTSP互動過程
C表 示RTSP客戶端，S表示RTSP服務端
① C->S: OPTION request //詢問S有 哪些方法可用
S->C: OPTION response //S回 應資訊中包括提供的所有可用方法
② C->S: DESCRIBE request //要求得到S提供 的媒體初始化描述資訊
S->C: DESCRIBE response //S回 應媒體初始化描述資訊，主要是sdp
③ C->S: SETUP request //設定會話屬性，以及傳輸模式，提醒S建 立會話
S->C: SETUP response //S建 立會話，返回會話識別符號及會話相關資訊
④ C->S: PLAY request //C請求播放
S->C: PLAY response //S回 應請求資訊
S->C: 傳送流媒體資料
⑤ C->S: TEARDOWN request //C請 求關閉會話
S->C: TEARDOWN response //S迴應請求
上述的過程是標準的RTSP流程，其中第3步和第4步是必需的。
http和rtsp在功能上有相似重疊的地方，RTSP採用了HTTP/1.1 大多數的狀態碼，並且增加了RTSP特定的狀態碼。
HTTP協議定義了8種可能的請求方法：
————————————
GET 檢索URI中標識資源的一個簡單請求
HEAD 與GET方法相同，伺服器只返回狀態行和頭標，並不返回請求文件
POST 伺服器接受被寫入客戶端輸出流中的資料的請求
PUT 伺服器儲存請求資料作為指定URI新內容的請求
DELETE 伺服器刪除URI中命名的資源的請求
OPTIONS 關於伺服器支援的請求方法資訊的請求
TRACE Web伺服器反饋Http請求和其頭標的請求
CONNECT 已文件化但當前未實現的一個方法，預留做隧道處理
————————————
rtsp和http的協議規範分別在RFC2326 和 RFC2616有詳細描述
mms協議為微軟的私有協議，未公開協議。採用私有自定義控制結構體來發送命令，而不是像http，rtsp協議採用傳送文字命令控制
RTP/RTSP/RTCP的區別 用一句簡單的話總結：RTSP發起/終結流媒體、RTP傳輸流媒體資料 、RTCP對RTP進行控制，同步。
RTSP與RTP
RTP不象http和ftp可完整的下載整個影視檔案，它是以固定的資料率在網路上傳送資料，客戶端也是按照這種速度觀看影視檔案，當影視畫面播放過後，就不可以再重複播放，除非重新向伺服器端要求資料。
RTSP與RTP最大的區別在於：RTSP是一種雙向實時資料傳輸協議，它允許客戶端向伺服器端傳送請求，如回放、快進、倒退等操作。當然，RTSP可基於RTP來傳送資料，還可以選擇TCP、UDP、組播UDP等通道來發送資料，具有很好的擴充套件性。它時一種類似與http協議的網路應用層協議。目前碰到的一個應用：伺服器端實時採集、編碼併發送兩路視訊，客戶端接收並顯示兩路視訊。由於客戶端不必對視訊資料做任何回放、倒退等操作，可直接採用UDP+RTP+組播實現。如下圖所示
RTP傳輸音訊/視訊資料，如果是PLAY，Server傳送到Client端，如果是RECORD，可以由Client傳送到Server
整個RTP協議由兩個密切相關的部分組成：RTP資料協議和RTP控制協議（即RTCP）。
RTSP的請求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顧名思義可以知道起對話和控制作用
RTSP的對話過程中SETUP可以確定RTP/RTCP使用的埠，PLAY/PAUSE/TEARDOWN可以開始或者停止RTP的傳送
RTSP其他
RTSP在制定時較多地參考了HTTP/1.1協議，甚至許多描述與HTTP/1.1完全相同。RTSP之所以特意使用與HTTP/1.1類似的語法和操作，在很大程度上是為了相容現有的Web基礎結構，正因如此，HTTP/1.1的擴充套件機制大都可以直接引入到RTSP中。 由RTSP控制的媒體流集合可以用表示描述（Presentation Description）來定義，所謂表示是指流媒體伺服器提供給客戶機的一個或者多個媒體流的集合，而表示描述則包含了一個表示中各個媒體流的相關資訊，如資料編碼/解碼演算法、網路地址、媒體流的內容等。 雖然RTSP伺服器同樣也使用識別符號來區別每一流連線會話（Session），但RTSP連線並沒有被繫結到傳輸層連線（如TCP等），也就是說在整個RTSP連線期間，RTSP使用者可開啟或者關閉多個對RTSP伺服器的可靠傳輸連線以發出RTSP 請求。此外，RTSP連線也可以基於面向無連線的傳輸協議（如UDP等）。
RTSP協議目前支援以下操作： 檢索媒體：允許使用者通過HTTP或者其它方法向媒體伺服器提交一個表示描述。如表示是組播的，則表示描述就包含用於該媒體流的組播地址和埠號；如果表示是單播的，為了安全在表示描述中應該只提供目的地址。 邀請加入：媒體伺服器可以被邀請參加正在進行的會議，或者在表示中回放媒體，或者在表示中錄製全部媒體或其子集，非常適合於分散式教學。 新增媒體：通知使用者新加入的可利用媒體流，這對現場講座來講顯得尤其有用。與HTTP/1.1類似，RTSP請求也可以交由代理、通道或者快取來進行處理。
SRTP & SRTCP
參考 RFC3711
安全實時傳輸協議（Secure Real-time Transport Protocol或SRTP）是在實時傳輸協議（Real-time Transport Protocol或RTP）基礎上所定義的一個協議，旨在為單播和多播應用程式中的實時傳輸協議的資料提供加密、訊息認證、完整性保證和重放保護。它是由David Oran（思科）和Rolf Blom（愛立信）開發的，並最早由IETF於2004年3月作為RFC3711釋出。
由於實時傳輸協議和可以被用來控制實時傳輸協議的會話的實時傳輸控制協議（RTP Control Protocol或RTCP）有著緊密的聯絡，安全實時傳輸協議同樣也有一個伴生協議，它被稱為安全實時傳輸控制協議（Secure RTCP或SRTCP）；安全實時傳輸控制協議為實時傳輸控制協議提供類似的與安全有關的特性，就像安全實時傳輸協議為實時傳輸協議提供的那些一樣。
在使用實時傳輸協議或實時傳輸控制協議時，使不使用安全實時傳輸協議或安全實時傳輸控制協議是可選的；但即使使用了安全實時傳輸協議或安全實時傳輸控制協議，所有它們提供的特性（如加密和認證）也都是可選的，這些特性可以被獨立地使用或禁用。唯一的例外是在使用安全實時傳輸控制協議時，必須要用到其訊息認證特性。