RTP 協議

概述：

實時傳送協議（Real-time Transport Protocol或簡寫RTP，也可以寫成RTTP）是一個網絡傳輸協議，它是由IETF的多媒體傳輸工作小組1996年在RFC 1889中公佈的。

RTP協議詳細說明了在互聯網上傳遞音頻和視頻的標準數據包格式。它一開始被設計爲一個多播協議，但後來被用在很多單播應用中。RTP協議常用於流媒體系統（配合RTCP協議或者RTSP協議）。因爲RTP自身具有Time stamp所以在ffmpeg 中被用做一種formate.

RTP協議格式：

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
上圖引自rfc3550，由上圖中可知道RTP報文由兩個部分構成--RTP報頭和RTP的負載：

RTP報文由兩部分組成：報頭和有效載荷。RTP報頭格式如圖6.7所示，其中：

1.V：RTP協議的版本號，佔2位，當前協議版本號爲2。

2. P：填充標誌，佔1位，如果P=1，則在該報文的尾部填充一個或多個額外的八位組，它們不是有效載荷的一部分。

3. X：擴展標誌，佔1位，如果X=1，則在RTP報頭後跟有一個擴展報頭。

4. CC：CSRC計數器，佔4位，指示CSRC 標識符的個數。

5. M: 標記，佔1位，不同的有效載荷有不同的含義，對於視頻，標記一幀的結束；對於音頻，標記會話的開始。

6. PT: 有效載荷類型，佔7位，用於說明RTP報文中有效載荷的類型，如GSM音頻、JPEM圖像等,在流媒體中大部分是用來區分音頻流和視頻流的，這樣便於客戶端進行解析。

7. 序列號：佔16位，用於標識發送者所發送的RTP報文的序列號，每發送一個報文，序列號增1。這個字段當下層的承載協議用UDP的時候，網絡狀況不好的時候可以用來檢查丟包。同時出現網絡抖動的情況可以用來對數據進行重新排序，在helix服務器中這個字段是從0開始的，同時音頻包和視頻包的sequence是分別記數的。

8. 時戳(Timestamp)：佔32位，時戳反映了該RTP報文的第一個八位組的採樣時刻。接收者使用時戳來計算延遲和延遲抖動，並進行同步控制。

9. 同步信源(SSRC)標識符：佔32位，用於標識同步信源。該標識符是隨機選擇的，參加同一視頻會議的兩個同步信源不能有相同的SSRC。

10. 特約信源(CSRC)標識符：每個CSRC標識符佔32位，可以有0～15個。每個CSRC標識了包含在該RTP報文有效載荷中的所有特約信源。

如果擴展標誌被置位則說明緊跟在報頭後面是一個頭擴展，其格式如下：

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      defined by profile       |           length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        header extension                       |
   |                             ....                              |

RTP協議的用途：

概述中已經基本闡述了ＲＴＰ協議的用途了，其主要用於在互聯網上傳遞音頻和視頻的標準數據包。在當前三網融合中ＲＴＰ可以用來承載TS流，進行電視媒體數據的傳播。ＲＴＰ可以用來傳送像TS流這種自身已經具有ｆｏｒｍａｔｅ的媒體流，同時也可以用來承載ＡＶＣ，ＡＡＣ等去除了fromate的媒體流，這時rtp協議可被看做爲一種formate，這種形式最少常見於helix 流媒體服務器的rtp流。其控制流由RTSP協議來提供。

RTP協議的使用：

ＲＴＰ的使用實例之一如上圖：

上面是某省IPTV２.０早期的一個數據包的情況。從包中可以看出RTP是怎麼和RTSP配合一起使用的。從包402到411爲RTSP的協商過程，RTSP在PLAYer命令後數據包就到來。緊跟其後412包就是一個mpeg 的PES包，它是有由rtp來承載的TS來形成。從在420包中就可以更加清析的看出這個RTP流的情況。其PT即payload type爲mpeg2 transport streams 也就是ts流，其SSRC爲：0x65737D6c，其Seq號爲15764，從中也可以看出對於一個RTP流其SEQ號可以開始於一個隨機的數值，但是肯定是逐包遞增的。下圖爲420包的展開圖：