RTP糾錯機制精選翻譯

9. 糾錯機制

9.1 前向糾錯(FEC)

  前向糾錯(FEC)算法能讓二進制流在傳輸過程中保持健壯性。傳送大量二進制流在鬆散的媒介或網絡下。額外的信息會加在二進制流中，能讓接受者正確的重構在傳輸中丟失的數據。前向就戳算法主要應用在廣域網，如手機網絡、或包交換網絡、或存儲系統(如壓縮盤、電腦硬盤或內存)。因爲因特網是一個鬆散的媒介，因爲媒體應用的信息對丟失非常敏感，FEC方案就被提議和編程RTP應用的標準。FEC方案能完成解壓，和準確重構二進制流，取決FEC類型、應用數量，和丟失的方式。

  當RTP應用FEC，就必須設計一下加入多少個FEC報文，取決於網絡丟失數據的大小。一個方法就是，用RTCP RR報文中的loss fraction(丟失率)來決定加入多少FEC數據到媒體流中。

  理論上，通過改變媒體編碼，是有可能確保一定丟失率下的糾錯。但實際上，很多情況都表明，FEC只提供可能性的修復。關鍵點在於FEC報文的加入也增加了帶寬消耗。帶寬增加侷限了FEC加入到有容量限制網絡的總數，如果是因爲網絡擁塞造成丟包，FEC有可能造成更壞的影響。因爲，帶寬消耗增加會加重網絡擁塞。這個會在本章後面的章節討論。

  注意雖然FEC的數量根據接收者質量報告而變化，對報文丟失並不發送反饋，並且也不能保證所有的丟失報文都能修復。目的是讓丟失率降低到能接受的丟失率，然後讓錯誤隱藏解決剩下的錯誤率。

  如果FEC正常工作的話，錯誤糾正肯定是侷限的，而且只在某些侷限的模式下，丟失報文才能被糾正。比如說，FEC方案只能去修復小於5%的丟失率，如果報文丟失率高達10%就無法正常糾錯了。另外一個限制是，在%5丟失率下，只有非連續報文的丟失才能被修復(sequence連續的報文丟失，FEC是無法修復的)。

  FEC最大的優點是，它能覆蓋很大的通信組，或者通信組直接不需要錯誤反饋。基於丟失率和丟失模式場景，加入一定量的糾錯冗餘的報文，所有接收者都能兼容。

  FEC缺點是過分依賴平均報文丟失率。當前報文丟失率低於平均的接收者接收到FEC冗餘糾錯報文，這些糾錯報文就僅僅是浪費帶寬，並肯定當做無用而丟棄。而高於平均丟失率的接收者就無法修復這些錯誤，只能靠錯誤隱藏來解決這些錯誤。如果各個接收者的錯誤率是不一樣的，僅僅一種FEC方式是無法讓所有接收者滿意。

  FEC的其他缺點是，FEC會引入演示，因爲修復必須要等到收到FEC報文。如果保護某些RTP報文的FEC報文一直沒有收到，那接收者只能要麼播放破損的RTP報文，要麼等待FEC到來，但等待肯定就增加了延時。對於交互性很強的應用影響很大，因爲這些應用非常需要低延時。

  FEC的方案很多，有幾種FEC對RTP協議非常適合。我們先過一下一些獨立於音視頻的FEC技術–校驗FEC和裏德.所羅門編碼，今後在討論針對特定音頻、視頻的FEC。

9.1.1 Parity FEC(校驗FEC)

  一種最簡單的FEC編碼方式就是校驗編碼。校驗計算數學上叫做比特流的異或，XOR。XOR是基於比特位的邏輯操作，兩個輸入下的操作是。

0 XOR 0 = 0
1 XOR 0 = 1
0 XOR 1 = 1
1 XOR 1 = 0

計算公式能容易擴展到多個XOR輸入:

A XOR B XOR C = (A XOR B) XOR C = A XOR (B XOR C)

  改變一個XOR的輸入會改變結果，那麼用XOR的結果就可以去檢測錯誤。這個XOR的能力靠這些值的多少來限制，但是當多個比特位都進行XOR，就能監測和修正錯誤。

  把XOR用在RTP系統中，關鍵點就是錯誤限制在丟包，而不是包內部比特位錯誤–也就是必須發送單獨的保護媒體數據的XOR報文。如果有足夠的XOR比特數據，這些XOR比特數據就能拿來修復那個丟失的報文，這個修復的方法如下:

A XOR B OXR B = A

  對於所有類型bit值，如果我們分別發送3個值：A, B 和 A X0R B，這3個報文只要收到其中兩個，另外一個都能被恢復。圖9.1顯示7爲bit的修復過程，當然其實能對任意長度的bit流進行修復。這個過程會被直接應用到RTP報文中，就是把整個RTP報文當做一組bit流，然後計算幾個RTP報文的XOR結果，這個XOR結果就能用作丟失恢復。

  RTP的校驗FEC標準在RFC2733。這個RFC標準內容是定義RTP報文總體FEC方案，滿足所有類型的負載類型payload type，並且後向兼容那些不處理FFEC報文的接受者。FEC報文是通過源RTP報文計算得到的。這些FEC報文作爲獨立的RTP報文來發送，FEC報文能用來修復源報文的丟失，如圖9.2。

9.1.2 校驗FEC報文格式

  FEC報文格式如圖9.3，主要有3部分:

• 標準RTP頭
• FEC負載頭
• 負載數據本身

  FEC報文是通過對被保護的RTP報文組進行XOR計算產生的，RTP報文計算內容是算上rtp header extension相關信息的。也就是對所有的RTP報文對應內容進行XOR計算，結果保存在FEC中。

• version, playload type, sequence number 和timestamp和普通的RTP報文方式一樣。payload type可以基於RTP規程動態定義；sequence對每個FEC報文進行自增;timestamp是要保護RTP報文的時間戳時鐘，具體數值是記錄FEC的時刻。(FEC的timestamp不一定等於媒體RTP的timestamp)。也就是說，FEC報文的時間戳單獨自增，完全獨立。
• padding，extension，CC和marker bits這4個字段，是通過對原始報文對應字段進行XOR計算得到。如果原始報文丟失，這些原始報文中的字段就能被恢復。
• CSRC列表和header extension不在FEC頭中，CC和X字段完全獨立。如果csrc列表和header extension在源RTP報文中，這些內容會被包含在FEC報文的payload負載內容中(就是在FEC payload header後)
  

  FEC payload header保護源RTP頭字段，這些字段沒有在FEC報文的RTP header中出現，具體有這6個字段:

• sequence number base. 被保護RTP報文組最小的sequence number
• Length recovery. 原始RTP負載報文組各自長度的XOR結果。各自的長度是指payload數據，csrc列表，header extension，和padding。當不知道丟失報文的payload長度是，通過FEC計算就可以得出。
• Extension(E). 表示FEC頭中是否有額外的字段。通常該字段設置爲0，表示沒有額外字段(ULP格式，在本章後面介紹，用extension字段表示多層FEC)
• Mask. 這個是bit mask，表示在sequence number base只有有哪些報文是在FEC保護中。如果bit i被設置成1，就是說 sequence number N+i已經被計算在FEC報文中，屬於被保護對象了，這裏的N就是sequence number base。最小i=0，最大i=23，也就是說FEC最大能一次保護24個RTP報文，這些報文可以是不連續的。
• Timestamp recovery. 該字段是原始報文的timestamp XOR結果。
  

  FEC payload data 是 CSRC list(如果存在)，header extension(如果存在) 和 源RTP報文payload data的XOR結果。如果一組RTP報文的數據長度都各不相同，最小的那個RTP報文就用pad來填充到最大那個RTP報文的長度(這個padding bits具體內容並不重要，只要每次保持用一樣的值就可以了，通常使用0值就可以了)。

9.3 糾錯重傳

  如果接受者向發送者發送消息，索要丟失的報文，丟失的報文就能避免。對於糾錯機制來說，重傳是常規的方法，它能在各種場景中應用。當然重傳也有其應用的侷限性。重傳並不是RTP標準協議的一部分；但是，RTP配套的文檔也在發展中，它應用基於RTCP的框架來發送重傳請求和其他的即時反饋機制。

9.3.1 RTCP的重傳機制

  因爲RTP包括了基於RTCP通道的反饋機制，如RR和其他的數據，很子軟的也就用RTCP通道來進行重傳請求。需要兩部分:

• RTCP重傳請求報文格式定義
• 允許立即反饋的時間準則

9.3.2 RTCP重傳請求格式

  RTP配套體系中對於重傳請求，定義了兩種額外的RTCP報文：

• 收包反饋: 反饋一組已經收到的報文
• 丟包反饋: 最常用的是丟包反饋，向發送者報告一組丟失的報文
  
    丟包反饋格式(negative acknowledgment，今後簡稱NACK)，在圖9.11中顯示。NACK包含一個packeg identifier，其標識一個丟失的報文，其後面的字段bitmap of lost packets標識該報文後面16個報文哪幾個丟失了，1代表丟失，0表示收到。即使收到NACK報文中bitmap字段中有0，發送者也不應該假想接受者已經收到該報文；只能確認到接受者當前並沒有上報該RTP報文丟失。當接收到一個NACK，發送者應該重傳NACK中標識丟失的RTP報文，雖然協議中沒有強制這麼做。
  
  
    ACK格式如圖9.12所示。ACK報文包含RTP sequnece，其代表已經收到的RTP報恩，和bitmap或後面的報文個數。如果R設置1，表示後面的報文個數，如果R設置0，表示bitmap後面15個具體哪幾個已經也收到了。這兩個選擇允許ACK針對少量丟失(R=1)，和ACK分散的丟失(R=0)。
  
    ACK和NACK用哪一個取決於具體修復算法和期望的機制。ACK表示部分報文收到了;發送者認爲其他的丟失了。相反，NACK表示部分報文丟失了，而其他的報文也許收到，也許沒收到(比如，當某個重要報文丟失需要重傳，接受者針對這個報文發送NACK，但忽略其他不重要的報文信息)。
  
    這樣的反饋報文的發送也是作爲RTCP組合報文的一部分，同其他的RTCP報文一樣。反饋報文放在組合報文的最後，如在SR/RR和SDES後面。(見第五章，RTCP，具體RTCP格式介紹)