組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：范晨 (fanchen  fan-chen@china.com)
譯文發布時間：2001-10-11
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須
保留本文檔的翻譯及版權信息。


Network Working Group                                       J. Rosenberg
Request for Comments: 2733                                   dynamicsoft
Category: Standards Track                                 H. Schulzrinne
                                                     Columbia University
                                                           December 1999

前向糾錯（FEC）的RTP荷載格式
（RFC2733——An RTP Payload Format for Generic Forward Error Correction）


本備忘錄狀態 
本文檔講述了一種Internet通信的標準Internet跟蹤協議,并對其改進提出了討論和建
議。請參考最新版本的"Internet Official Protocol Standards" (STD 1) 來獲得本協議的
標準化進程和狀態，此備忘錄的發布不受任何限制。
版權注意
版權歸因特網協會（1999）所有，保留一切權利。
摘要
本文檔規定了一般性的前向糾錯的媒體數據流的RTP打包格式。這種格式針對基于異或
操作的FEC算法進行了特殊設計，它允許終端系統使用任意長度的糾錯碼，并且可以同時恢
復出荷載數據和RTP頭中的關鍵數據。由于FEC作為一個分離的數據流進行傳送，這種方案
可以向后兼容那些沒有實現FEC解碼器的接收終端。對于那樣的終端來說，可以簡單地將FEC
數據丟掉。

目  錄
1 簡介	2
2 術語	2
3 基本操作	3
4 監督碼	3
5 RTP媒體數據包結構	5
6 FEC包結構	5
6.1 FEC包的RTP包頭	5
6.2 FEC頭	5
7 保護操作	6
8 恢復過程	7
8.1 重建	7
8.2 何時進行恢復	8
9 例子	11
10 冗余編碼中使用FEC的用法	13
11 在SDP中表示FEC	14
11.1 FEC作為獨立的流傳輸	14
11.2在冗余編碼中使用FEC	15
11.3 在RTSP中的用法	16
12 安全性問題	16
13 致謝	17
14 作者地址	17
15 參考書目	17
16.版權聲明	18
致謝	18

1 簡介
在Internet上用分組傳送話音的質量不夠好的一個重要原因是比較高的丟包率。尤其在
廣域網中，這個問題相當突出。不幸的是，實時多媒體業務對于延時的要求相當嚴格，因此
不大可能通過重傳來解決丟包的問題。
正是出于這個原因，大家提出用前向糾錯（FEC）來解決Internet上的丟包問題[1][2]。
尤其是對于傳統糾錯碼如校驗碼、RS碼、漢明碼等的使用引起了很多人的注意。為了能夠更
好地應用這些糾錯碼，必須有相關的協議來支持。
本文檔定義了一種RTP的荷載格式，允許對于實時媒體流進行一般性的前向糾錯。在這
里“一般性”指的是（1）與被保護的媒體類型無關，即音頻、視頻或其它；（2）足夠靈活，
能夠支持多種FEC機制；（3）自適應性，可以方便的修改FEC方案而不需要帶外的信令支持；
（4）支持若干種不同的FEC包的傳輸機制。
2 術語
本文檔中使用了下面這些術語：
媒體荷載：一段待傳輸的未加保護的用戶數據。媒體荷載放在一個RTP包的內部。
媒體頭：包含媒體荷載的包的RTP頭
媒體包：媒體荷載與媒體頭合起來稱作媒體包
FEC包：發送端將媒體包作為前向糾錯算法的輸入，輸出除了這些媒體包之外，還有一些
新的數據包稱作FEC包。FEC包的格式在本文檔中進行說明。
FEC頭：FEC包的頭信息稱作FEC頭。
FEC荷載：FEC荷載是FEC包中的荷載。
關聯的：一個FEC包稱作與一個或幾個媒體包是關聯的，如果在這個FEC包的產生過程
中這幾個媒體包用作EC算法的輸入
   關鍵詞“必須”，“必須不”，“要求的”，“會“，”不會“，“應該”，“不應該”，
“建議的”，“或許”，“可選的”在RFC2119[4]中解釋。
3 基本操作
這里描述的荷載格式用于一個RTP會話中的某一端想要用FEC來保護它所傳送的媒體數
據流的情況。這種格式所支持的FEC是基于簡單異或校驗的糾錯算法。發送端從媒體數據流
中取出若干個包，并對它們整個施以異或操作，包括RTP頭。基于這樣一個過程，可以得到
一個包含FEC信息的RTP包。這個包可以被接收端用來恢復任何一個用來產生它的包。本文
檔中并未規定多少個媒體包合起來產生一個FEC包。不同參數的選取會導致在overhead，延
時和恢復能力之間的一個不同的折中方案。第4節給出了一些可能的組合。
發送端需要告訴接收端哪些媒體包被用來產生了一個FEC包，這些信息都包含在荷載信
息中。每個FEC包中包含一個24比特的mask，如果mask的第i個比特為1，序號為N＋i
的媒體包就參與了這個FEC包的生成。N稱作基序號，也在FEC包中傳送。通過這樣一種方
案就可以以相當小的overhead來用任意的FEC糾錯方案恢復丟失的數據包。
本文檔也描述了如何使接收端在不了解具體糾錯碼細節的情況下利用FEC的方法。這就
給了發送端更大的靈活性，它可以根據網絡狀態而自適應選擇糾錯碼，而接收端仍能夠正確
解碼并用于恢復丟失的包。
發送端生成FEC包之后，就把它們發給接收端，同時，發送端也照常發送原來的媒體數
據包，就好像沒有FEC一樣。這樣對于沒有FEC解碼能力的接收端，媒體流也照常可以接收
并解碼。然而，對于某些糾錯碼來說，原始的媒體數據包是不需要傳輸的，僅靠FEC包就足
以恢復丟失的包了。這類碼就具有一個很大的缺點，就是要求所有的接收者都具有FEC解碼
能力。這類碼在本文檔中也是支持的。
FEC包并不與媒體包在同一個RTP流中傳輸，而是在一個獨立的流中傳輸，或者作為冗
余編碼（redundant encoding）中的次編碼（secondary encoding）來傳輸[5]。當在另一個
流中傳輸時，FEC包有它們自己的序號空間。FEC包的時間戳是從對應的媒體包中得來的，同
樣是單調遞增。因此，這樣的FEC包可以很好地應用于任何具有固定差值的包頭壓縮方案。
本文并沒有規定何為“一個獨立的流”，而把它留給上層協議和具體應用去定義。對于
多播的情況，“一個獨立的流”可以通過不同的多播組來實現，或者同一個組的不同端口，
或者同樣的組和端口中不同的SSRC。對于單播的情況，可以使用不同的端口或者不同的SSRC。
這些方法都各有其優缺點，選用哪一種取決于具體的應用。
接收端收到FEC包和媒體包之后，先判斷是否有媒體包丟失。如果沒有，FEC包就直接
被丟棄。如果有丟包，就使用接收到的FEC包和媒體包來進行丟包的重建。這樣一個重建過
程是很精確的，荷載以及包頭的大部分數據都可以完全恢復出來。
   按照本協議來進行打包的RTP包可以使用一個動態RTP荷載類型號來通知接收端。
4 監督碼
我們定義f(x,y,..)為數據包x,y,…等的異或，這個函數的輸出也是一個數據包，稱作
監督包。為簡單起見，我們假定監督包就是輸入的各個包的對應比特異或得到。詳細的過程
描述在第6節中給出。
用監督碼來恢復數據包是通過對一組數據包生成一個或多個監督包來完成的。為了提高
編碼的效率，這些監督包必須是數據包的線性無關的組合生成的。某一個特定的組合就稱為
一個監督碼。對于k個一組的數據包，生成n-k個監督包，這樣的監督碼認為是同一類監督
碼。對于給定的n,k，可能的監督碼有很多。荷載格式并未要求使用某個特定的監督碼。
   舉個例子，考慮這樣一種監督碼，輸入為兩個數據包，輸出為1一個監督包。如果原始媒
體數據包是a, b, c, d，發送端送出的包如下所示：

   a        b        c        d               <-- 媒體流
              f(a,b)            f(c,d)        <-- FEC流

   時間從左向右遞增。在這個例子里，糾錯碼帶來了50%的overhead。但是如果b丟失了，
用a和f(a,b)就可以恢復出b。
   下面還給出了一些其它的監督碼。其中每一個的原始媒體數據流都包含數據包a,b,c,d
等等。

   方案 1
   --------
   這個方案與上面的例子很類似。區別在于，并不是發送b之后再發送f(a,b)。f(a,b)在b
之前就發送出去了。顯然這樣做會給發送端帶來額外的延時，但是用這種方案能夠恢復出突
發的連續兩個丟包。發送端送出的包如下所示：

   a        b        c        d        e        <-- 媒體流
     f(a,b)   f(b,c)   f(c,d)   f(d,e)          <-- FEC流

   方案 2
   --------
   事實上，并沒有嚴格規定一定要傳送原始媒體數據流。在這個方案中，只傳送FEC數據包。
這種方案能夠恢復出所有單個的丟包和某些連續的丟包，而且overhead比方案1略小一些。
發送端送出的數據包如下所示：

   f(a,b)  f(a,c)  f(a,b,c)  f(c,d)  f(c,e)  f(c,d,e)  <-- FEC流

   方案 3
   --------
   這種方案要求接收端在恢復原始媒體數據包時等待4個數據包間隔的時間，也就是在接收
端引入了4個數據包的延時。它的優越性在于它能夠恢復出單個丟包，連續兩個丟包乃至連
續三個丟包。發送端送出的數據包如下所示：

   a         b          c                    d     <-- 媒體流
               f(a,b,c)    f(a,c,d) f(a,b,d)       <-- FEC流

5 RTP媒體數據包結構
   媒體數據包的結構并不受FEC的影響。如果FEC包作為一個獨立的流進行傳輸，媒體數據
包的傳輸就與不使用FEC時完全沒有區別。如果FEC作為一個冗余編碼（redundant codec）
來進行傳輸，媒體數據包就作為RFC2198[5]中定義的主編碼（primary codec）。
這樣一種編碼方式是非常高效的。如果只使用了極少量的FEC，大部分數據包都是媒體
數據包，這意味著overhead代表著FEC的冗余數據量。   
6 FEC包結構
   一個FEC包就是把一個FEC包頭和FEC包的荷載放進RTP包的荷載中組成的，如圖1所示。

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         RTP 頭                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         FEC 頭                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         FEC 荷載                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   圖 1: FEC包結構
6.1 FEC包的RTP包頭
在FEC包的RTP包頭中，版本域設定為2，填充位通過保護操作計算得到，具體方法在
后面給出。擴展位也是通過保護操作計算得到的。一般情況下，SSRC的值應當與它所保護的
媒體數據包的SSRC值一致。如果FEC流通過SSRC值來進行解復用的話，SSRC的值就有可能
會不同。CC的值也是在保護操作中計算出來。不管CC域為何值，CSRC列表永遠不存在。不
管X比特為何值，頭擴展部分永遠不存在。標記位的值通過保護操作計算得出。   
對于次序號有一個標準的定義：當前包的次序號必須比前一個包的次序號大1。時間戳
必須設定為當前這個FEC包發送時對應的媒體流的RTP時鐘的值。不管使用何種FEC方案，
FEC包頭中的TS值是單調遞增的。
FEC包的荷載類型是動態確定的，即在帶外通過信令來協商確定的。按照RFC1889[3]，
RTP會話的某一方如果不能識別收到的RTP包的荷載類型的話，就必須將其丟棄。這樣就很
自然地提供了向后兼容的能力。FEC機制可以用在一個多播的環境中，某些接收端具有FEC
解碼能力，而某些不具有。
6.2 FEC頭
   FEC頭的長度為12個字節，其格式如圖2所示。它包含一個SN基數域，長度恢復域，E
域，PT恢復域，mask域以及TS恢復域。

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      SN 基數                  |        長度恢復               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E| PT 恢復     |                 mask                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          TS 恢復                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   圖 2: FEC頭格式

長度恢復域用來確定待恢復的數據包的長度。它的值是當前組中被保護的媒體數據包的
長度（以字節為單位）的二進制和（逐位異或），用一個網絡序的16比特無符號整數表示。
在這里，媒體數據包的長度包括CSRC列表、擴展部分和填充的比特。這樣即使在媒體數據包
長度不一致的情況下，也一樣可以使用FEC。舉個例子，假定要用兩個媒體數據包的異或來
產生一個FEC包，這兩個媒體數據包的長度分別為3（0b011）和5（0b101）個字節，那么長
度恢復域的值就是0b011 xor 0b101 = 0b110。
比特E指示是否存在一個擴展部分。在當前版本中，這個比特必須設置為0。
PT恢復域是通過對相關的媒體數據包的荷載類型域的值進行異或操作得到的，從而能夠
用來恢復丟失包的荷載類型。
Mask域長度為24個比特，如果其中的第i個比特設置為1，那么序號為N+i的媒體數據
包就與當前FEC包相關聯。其中N是SN基數域的值。最低位（LSB）對應于i＝0，最高位（MSB）
對應于i＝23。
SN基數域的值必須設置為與當前FEC包相關的媒體數據包中的最小的序號。這樣一個FEC
包最多可以與連續24個媒體數據包相關聯。
TS恢復域是通過計算相關聯的媒體數據包的時間戳的異或得到的。這樣就可以恢復出丟
掉的數據包的時間戳。
FEC包的荷載是對相關聯的媒體數據包的CSRC列表、RTP頭部擴展、媒體包荷載以及填
充比特連在一起進行異或操作得到的。
值得注意的是FEC包的長度有可能會比它保護的媒體數據包的長度大一點，因為多了一
個FEC頭。如果FEC包的長度超出了下層協議允許的最大包長，這可能會給傳輸帶來很大的
問題。
7 保護操作
保護操作涉及到將RTP頭中的某些域與媒體包的荷載級聯起來，再加上填充比特，然后
對這些序列計算它們的異或值。得到的比特序列就成為FEC包的某個組成部分。
對于每一個要保護的媒體包，按照下面的次序將各個數據域級聯起來生成一個比特序列，
如果中間還插入了其它操作的話，最終結果必須與下面所描述的一致：
      o 填充位 （1比特）
      o 擴展位 （1比特）
      o CC （4比特）
      o 標記位 （1比特）
      o 荷載類型 （7比特）
      o 時間戳 （32比特）
      o 長度恢復域的值 （網絡次序16比特無符號整數），也就是各個媒體數據包的荷載
長度、CSRC列表長度以及填充比特長度的和異或的結果