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流。其控制流由

來提供。

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包的展開圖：

從中可以看出承載RTP的為UDP的資料流這個包中有x标志位為1則說明其有 header extensions.其header extensions為最下面。extension 的 profile為23128,長度為：2内容如上圖最後兩部分。