RTP、RTCP和RTSP協議基礎

1 RTSP概述

1.1 RTSP概念   

    RTSP(Real-Time Stream Protocol )是一種基於文本的應用層協議，在語法及一些消息參數等方面，RTSP協議與HTTP協議相似。

    RTSP被用於創建的控制媒體流的傳輸，它爲多媒體服務扮演「網絡遠程控制」的角色。RTSP自己並不用於傳送媒體流數據。媒體數據的傳送可經過RTP/RTCP等協議來完成。

1.2 基本的RTSP操做過程

   首先，客戶端鏈接到流服務器併發送一個OPTIONS命令查詢服務器提供的方法收到服務器的迴應後，發送DESCRIBE命令查詢某個媒體文件的SDP信息。流服務器經過一個SDP描述來進行迴應，迴應信息包括流數量、媒體類型等信息。客戶端分析該SDP描述，併爲會話中的每個流發送一個SETUP命令，SETUP命令告訴服務器客戶端用於接收媒體數據的端口。流媒體鏈接創建完成後，客戶端發送一個PLAY命令，服務器就開始傳送媒體流數據。在播放過程當中客戶端還能夠向服務器發送PAUSE等其餘命令控制流的播放。通訊完畢，客戶端可發送TERADOWN命令來結束流媒體會話。

1.3 RTSP與HTTP的區別

        能夠發現RTSP協議的格式與http協議很相似，都是基於文本的協議，語法也基本相同。可是它們並不相同，有如下主要差異：

       首先，方法名稱不一樣。RTSP新增了DESCRIBE、SETUP、PLAY等方法。

       其次，HTTP協議是無狀態的協議，方法之間的發送並沒有明顯的次序關係。而RTSP是有狀態的協議，各方法存在次序關係。

在者，HTTP協議能夠之內帶載荷數據的方式傳送數據，如網頁數據。而RTSP僅僅提供流播放的控制，並不傳送流媒體數據。流媒體數據能夠經過RTP/RTCP的方式傳送。

1.4 RTSP以及RTP等在TCP/IP協議簇中位置

2 RTSP消息

2.1 RTSP消息格式

2.1.1 RTSP請求消息格式

方法名稱 URL RTSP版本   回車換行     
     header   回車換行  回車換行
     body     回車換行

注意：方法名稱 包括OPTIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等。

    URL 是接受方的地址，如:rtsp://192.168.0.1/video1.3gp。

    RTSP版本通常是RTSP/1.0

    消息的每一行都會以回車換行結尾，爲了便於定位識別，消息頭header的最後一行有兩個回車換行。

    消息體body有時是可選的。

2.1.2 RTSP響應消息格式

RTSP版本  狀態碼  對應文本解釋  回車換行    
    header  回車換行  回車換行
    body    回車換行

註音：  RTSP版本 通常爲RTSP/1.0。

    狀態碼 表示對應消息的執行結果。

    部分狀態碼與文本解釋對應列表以下：

   狀態碼       文本解釋                      含義

  「200」         OK                              執行成功

  「400」         Bad Request                 錯誤請求

  「404」        Not Found                  未找到

  「500」        Internal Server Error   服務器內部錯誤

2.2 RTSP中各方法詳細介紹

2.2.1 OPTIONS

Client用OPTIONS來查詢Server提供的方法。Server在響應消息的public字段給出本身提供的方法集合。

注意：

1 OPTIONS方法並不是必須，Client能夠繞過OPTIONS，而直接向server發送其餘消息。

2 OPTIONS能夠再任什麼時候間發送。有的客戶端會定時向服務器發送OPTION消息。而服務器也能夠經過是否認時收到OPTIONS消息來判斷客戶端是否在線。但並非全部客戶端和服務器都這樣作。

Server給Client的響應消息的各個字段的含義：

A CSeq字段 請求的序號

客戶端的每個請求都會被賦值一個序號。每一個請求消息也會對應一個一樣序號的迴應消息。

B Public字段 Server給出本身提供的方法的集合。

Client給Server的請求消息的各個字段含義：

A UserAgent字段 用戶標識不一樣公司或是不一樣的客戶端

該域用於用戶標識不一樣公司或是不一樣的客戶端。不一樣客戶端發出的消息中的這個域的內容都不大相同。有時會指明客戶端的版本號、型號等等。

Clinet------>Server:
OPTIONS rtsp://10.34.3.80/D:/a.264 RTSP/1.0

CSeq: 2                                                                                              //請求序號

User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)

Server------>Client:
RTSP/1.0 200 OK

CSeq: 2                                                                                              //回覆序號

Date: Tue, Jul 22 2014 02:41:21 GMT

Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER

2.2.2 DESCRIBE

     DESCRIBE消息是由客戶端發送到服務器端，用於客戶端獲得請求連接中指定的媒體文件的相關描述，通常是SDP信息。

      Server把SDP放在RTSP的響應消息中發給Client。 SDP（Session Description Protocol）包含了會話的描述、媒體編碼類型、媒體的碼率等信息。對於流媒體服務而言，如下幾個域是在SDP中必定要包含的。

「a=control:」
「a=range:」
「a=rtpmap:」
「a=fmtp:」

     當一個錄像中即包含音頻又包含視頻時，會有多個上述結構。每一個媒體描述以m開始。m行又稱媒體行，描述了發送方所支持的媒體類型等信息，須要詳細說明下。a行爲媒體的屬性行，以屬性的名稱：屬性值的方式表示。

音頻的m行的格式：

    m=audio 3458  RTP/AVP  0   96   97       第一個參數audio爲媒體名稱：代表支持音頻類型。
    第二個參數3488爲端口號，代表UE在本地端口爲3458上發送音頻流。
    第三個參數RTP/AVP爲傳輸協議，表示基於UDP的RTP協議。
    第四到七個參數爲所支持的四種淨荷類型編號。
    a=rtpmap:0   PCMU
    a=rtpmap:96  G726-32/8000
    a=rtpmap:97  AMR-WB
    a行爲媒體的屬性行，以屬性的名稱：屬性值的方式表示。
   格式爲：a=rtpmap:<淨荷類型><編碼名稱> 
   淨荷類型0固定分配給了PCMU，
   淨荷類型96對應的編碼方案爲G.726,爲動態分配的。
   淨荷類型97對應的編碼方式爲自適應多速率寬帶編碼（AMR-WB），爲動態分配的。

視頻的m行的格式：

   m=video 3400 RTP/AVP 98  99   第一個參數video爲媒體名稱：代表支持視頻類型。
   第二個參數3400爲端口號，代表UE在本地端口爲3400上發送視頻流。
   第三個參數RTP/AVP爲傳輸協議,表示RTP over UDP。
   第4、五參數給出了兩種淨荷類型編號
   a=rtpmap:98  MPV
   a=rtpmap:99  H.261
   淨荷類型98對應的編碼方案爲MPV,爲動態分配的。
   淨荷類型97對應的編碼方式爲H.261，爲動態分配的。

Server給Client的響應消息的各個字段的含義：

A Content-Base字段   指明對某個媒體的描述信息

B Content-Typte字段   請求類型

C Content-Length字段  SDP的長度（由於這裏的body中）

Client給Server的請求消息的各個字段含義：

A Accept字段  用於指定客戶端能夠接受的媒體描述信息類型，此處爲SDP信息。

2.2.3 SETUP

SETUP消息用於肯定轉輸機制，創建RTSP會話。

注意：客戶端也能夠在創建RTSP後再次發出一個SETUP請求爲正在播放的媒體流改變傳輸參數，服務器可能贊成這些參數。若不一樣意，會迴應 "455 Method Not Valid In This State"。

Server給Client的響應消息的各個字段的含義：

A Transport字段  由服務器確認後的傳輸參數

Client給Server的請求消息的各個字段含義：

A Transport字段  客戶端可接受的數據傳輸參數

若是該請求不包含SessionID，則服務器會產生一個SessionID。

例子1：使用RTP over UDP方式

Client-------------->Server:
SETUP rtsp://10.34.3.80/D:/a.264/track1 RTSP/1.0   //track1表示對1號通道進行設置

CSeq: 4

User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)   //客戶端版本信息

Transport: RTP/AVP;unicast;client_port=60094-60095       //約定傳輸參數 RTP/AVP表示採用RTP over UDP， unicast表示單播，用以區別組播。Client_port約定客戶端RTP端口爲60094，RTCP端口爲60095

Server-------------->Client:
RTSP/1.0 200 OK

CSeq: 4

Date: Tue, Jul 22 2014 02:41:25 GMT

Transport: RTP/AVP;unicast;destination=10.34.3.80;source=10.34.3.80;client_port=60094-60095;server_port=6970-6971 //服務器端所指定的傳輸參數
這裏要注意：RTP用偶數端口，RTCP爲相鄰的奇數端口
Session: 54DAFD56;timeout=65    //SessionID

例子2: 使用RTP over TCP方式

CLient--------------->Server: request 消息
SETUP rtsp://10.34.3.80/D:/a.264/track1 RTSP/1.0   //track1表示對1號通道進行設置
CSeq: 4
User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)  
Transport: RTP/AVP/TCP;unicast;interleaved= 0-1
SETUP命令的Transport字段爲RTP/AVP/TCP，同時多了一個interleaved=0-1字段。
因爲RTP over TCP將RTP包和RTCP包發至同一個TCP端口，
所以使用interleaved的值來區分究竟是RTP仍是RTCP包。I
nterleaved=0表示RTP包，interleaved=1表示RTCP包。

Server--------------->Client：response 消息
RTSP/1.0 200 OK
CSeq: 4
Date: Tue, Jul 22 2014 02:41:25 GMT
Transport: RTP/AVP/TCP;interleaved=0-1
Session: 54DAFD56;timeout=65

2.2.4 PLAY

PLAY方法通知服務器按照SETUP中指定的機制開始傳送數據。服務器會從PLAY消息指定範圍的開始時間開始傳送數據，直到該範圍結束。

注意：服務器可能會將PLAY請求放到隊列中，後一個PLAY請求須要等待前一個PLAY請求完成才能獲得執行。

Client給Server的請求消息的各個字段含義：

A Range字段 指定了播放開始的時間。

若是在這個指定時間後收到消息，那麼播放當即開始。不含Range頭的PLAY請求也是合法的，此時將從媒體流開始位置播放，直到媒體流被暫停。若是媒體流經過PAUSE暫停，媒體流傳輸將在暫停點繼續傳輸。若是媒體流正在播放，那麼該PLAY請求將不起做用。客戶端能夠利用此來測試服務器是否存活。

例子：

Client----------->Server:
PLAY rtsp://10.34.3.80/D:/a.264/ RTSP/1.0
CSeq: 5
User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)
Session: 54DAFD56                 //SessionID，SETUP迴應中返回
Range: npt=0.000-   /                /指定開始播放的時間
Server----------->Client:
RTSP/1.0 200 OK
CSeq: 5
Date: Tue, Jul 22 2014 02:41:25 GMT
Range: npt=0.000- 
Session: 54DAFD56
RTP-Info: url=rtsp://10.34.3.80/D:/a.264/track1;seq=10244;rtptime=2423329550  //RTP信息
Url字段爲RTP參數對應的流媒體連接地址，seq字段爲流媒體第一個包的序列號，rtptime爲range域對應的RTP時間戳

2.2.5 PAUSE

PAUSE消息通知服務器暫停流傳輸的傳輸。

若是請求URL中指定了具體的媒體流，那麼只有該媒體流的播放被暫停。能夠指定僅暫停音頻，此後的播放將會靜音。

若是請求URL指定了一組流，那麼在該組中的全部流的傳輸將被暫停。

注意：服務器有可能不支持PAUSE消息。例如，實時流就有可能不支持暫停。當一個服務器不支持某一個消息時，會迴應給客戶端「501 Not Implemented」。

Client給Server的請求消息的各個字段含義：

A Range字段（可選）  用來指定媒體流暫停的時間點，稱之爲暫停點。

這裏的Range頭必須包含一個精確的值，而不是一個時間範圍。若是Range頭指定了一個時間超出了PLAY請求的範圍，服務器將將返回"457 Invalid Range" 。若是Range頭缺失，那麼在收到暫停消息後媒體流傳輸當即暫停，並將暫停點設置成當前播放時間。

2.2.6 TEARDOWN

TEARDOWN請求終止了給定URL的媒體流傳輸，並釋放了與該媒體流相關的資源。

3 RTP、RTCP協議

3.1 RTP協議

1 RTP概述

RTP是實時傳輸協議（Real-Time Transport Protocol）的縮寫，是針對多媒體數據流的實時傳輸協議。

一般創建在UDP協議之上，也能夠創建在TCP協議之上。有人將其歸爲應用層協議，也有人將其歸爲傳輸層協議，這都是能夠的。

Rtp協議提供了時間戳和序列號。發送端在採樣時設置時間戳，接收端收到後，會按照時間戳依次播放。RTP自己只保證明時數據的傳輸，並不能爲按順序傳送的數據包提供可靠的傳送機制，也不提供流量和擁塞控制，它依靠RTCP來提供這些服務。

2 RTP報文格式

   版本號（V）:0-1  2b 用來標識使用的RTP版本。

    填充位（P）:2  1b 若是該位被置爲1，則RTP包的尾部會跟附加的填充字節。

    擴展位（X）：3 1b 若是該位被置爲1，則RTP包的尾部會跟附加擴展幀頭。

    CSRC計數器（CC）: 4-7 4b 固定頭部後跟着的CSRC數目。

    標記位（M）: 8 1b 該位的解釋由配置文檔解釋。

    載荷類型（PT）:9-15 7b標識RTP載荷的類型。

    序列號（SN）: 16- 31 16b發送方在發送完每個RTP包後會將該域 的值加1，接收方能夠經過檢測序列號來判斷是否出現RTP丟包現象。注意：序列號的初始值是隨機的。

    時間戳：32 32b 該包中第一個字節的採樣時刻。時間戳有一個初始值，隨着時間的流逝而不斷增長。即便此時沒有包被髮出，時間戳也會不段增長。時間戳是實現去除抖動和實現同步必不可少的。

    SSRC:同步源標識符： 32b  RTP包的來源，在同一個RTP會話中不能 有兩個相同的SSRC值。該字段是根據必定的算法隨機生成。

    CSRC List:貢獻源列表 0-15個，每項32b 用來標識對一個RTP混合器產生的新包有貢獻的全部RTP包的源。

3.2 RTCP協議

1 RTCP協議概述

RTCP是實時控制協議（Real-Time Control Protocol）的縮寫。RTCP一般與RTP配合使用，用以管理傳輸質量在當前進程之間的交換信息。

在RTP會話期間，各參與者週期性的傳送RTCP包，RTCP包中包含已發送數據包的數量、丟失的數據包的數量等統計資料。服務器能夠利用這些信息動態的改變傳輸速率，甚至改變有效載荷的類型。

RTP和RTCP配合使用，能夠有效且以最小的開銷達到最佳傳輸效率，很是適合傳送實時流。

2 RTCP協議的端口以及五種包

RTSP一般使用RTP協議來傳送實時流，RTP通常使用偶數端口，而RTCP使用相鄰的奇數端口，即RTP端口號+1。

在RTCP通訊控制中，RTCP協議的功能是經過不一樣類型的RTCP包來實現的。RTCP也是基於UDP包來傳送的，主要有五種類型的封包：

    1.SR：發送端報告，由發送RTP數據報的應用程序或中端發出的。

    2.RR：接收端報告，由接受但不發送RTP數據報的應用程序或中端發出。

    3.SDES: 源描述，傳遞與會話成員有關的標識信息的載體，如用戶名、郵件、電話等。

   4.BYE: 通知離開，通知回話中的其餘成員將退出會話。

   5.APP: 由應用程序本身定義，做爲RTCP協議的擴展。

3 RTCP協議報文格式

    版本（V）：同RTP包頭部

    填充(P) ：同RTP包頭部。

    接收報告計數器（RC）:5b 該SR包中接收的報告塊的數目。

    包類型（PT）： 8bit SR包類型爲200

    長度（length）：SR包以32bit爲1單位的長度減1

    同步源（SSRC）：SR包發送的同步源標識符。與對應RTP包中的SSRC同樣。

    NTP時間戳（Network Time Protocol）:SR包發送時的絕對時間。用於同步不一樣的流。

    RTP時間戳：與NTP時間戳對應，與RTP包中的時間戳具備相同的初始值。

    Send’s Packet count：從開始發包到產生這個SR包的這段時間內發送者發送的有效數據的總字節數，不包括頭部和填充，發送者改變SSRC時，該域要清零。

    同步源n的SSRC標識符：該報告中包含的是從該源接收到的包的統計信息。

    丟失率：代表從上一個SR或RR包發出依來從同步源n發送的RTP包的丟失率。

    累計丟失數據：從開始接受SSRC_n的包到發送SR這個時間段內SSRC_n發送的RTP丟失的總數目。

    收到的擴展最大序列號：從SSRC_n收到的從RTP數據包中的最大序列號。

    接收抖動（Interarrival jitter）：RTP數據包接收時間的統計方差估計。

    上次SR時間戳（Last SR）：取最近從SSRC_n收到的SR包中的NTP時間戳中的中間32bit。若是還未收到SR包，則爲0。

    上次依賴SR延遲（Delay since Last SR）：從上次SSRC_n收到SR包到發送本包的延遲

4 音視頻同步

傳送的音頻和視頻流位於兩個不一樣的RTP會話中，每一個RTP包均有本身的時間戳，同時RTCP包中的NPT字段（Network Protocol Time）保存的絕對時間能夠用來將音視頻映射到同一時間軸上，從而實現音視頻同步。