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


Network Working Group                                          S. Casner
Request for Comments: 2508                                 Cisco Systems
Category: Standards Track                                    V. Jacobson
                                                           Cisco Systems
February 1999


低速串行鏈路下IP/UDP/RTP數據包頭的壓縮
（RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links）

本備忘錄的狀態
  本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建議以
得到改進。請參考最新版的“Internet正式協議標準” (STD1)來獲得本協議的標準化程度
和狀態。本備忘錄的發布不受任何限制。
版權聲明
   Copyright (C) The Internet Society (1999).  All Rights Reserved.
摘要
本文描述了一種對IP/UDP/RTP數據報頭進行壓縮的方法，它可以降低在低速串行鏈路上
的網絡開銷。多數情況下，三個頭可壓縮到2-4字節。
請賜教并將您的建議發送到工作組郵件列表rem-conf@es.net或直接給作者。
本文中的關鍵字“必須”，“必須不”，“要求的”，“應該”，“不應該”，“會”，“不會”，
“建議”，“或許”，“可選的”在 RFC 2119 中解釋。   
目錄
本備忘錄的狀態	1
版權聲明	1
摘要	1
1. 介紹	2
2. 設想和折中	2
2.1. 單工與全雙工	3
2.2. 分片與分層	3
3.壓縮算法	3
3.1.基本概念	3
3.2 RTP數據包頭壓縮	4
3.3協議	5
3.4. RTCP控制包壓縮	12
3.5.非RTP UDP包壓縮	13
4.與分片的交互	13
5.壓縮協商	13
6.致謝	14
7.參考文獻	14
8. 安全性考慮	14
9.作者地址	15
10.版權聲明	15
1. 介紹
   隨著實時傳輸協議(RTP)成為正式的RFC[1]發行，人們對于利用RTP實現不同的網絡音視
頻應用程序間互操作的興趣也日益增長。然而，我們也注意到，當使用低速鏈路如14.4Kb/s
或28.8Kb/s撥號時，12字節的RTP頭對于僅有20字節的負載而言開銷實在太大。（為了減少
頭占用的字節，一些已經在類似環境下存在的應用通常使用自定義的協議，而這樣做的代價
就是削減了RTP相關的功能。）
   事實上，正如在TCP中已經取得巨大成功，也可通過壓縮技術來令IP/UDP/RTP包頭變小。
這時，壓縮可以針對于RTP頭（在端到端應用中），或者IP，UDP，RTP的組合頭（在Link-by-Link
應用中）。將40字節的組合頭一起進行壓縮比僅壓縮12字節的RTP頭更具實際效果，因為兩
種情況下的結果大小均為約2-4字節。同時，由于延遲和丟失率都很低，對Link-by-Link應
用進行壓縮性能上也更好。因此我們在這里定義的方法就是針對Link-by-link應用下
IP/UDP/RTP頭進行組合壓縮。
   本文定義的壓縮方案可應用于IPv4包、IPv6包或封裝了多個IP頭的包。為了能同時在IPv6
和IPv4下使用，這里定義的IP/UDP/RTP壓縮符合[3]中規定的通用壓縮框架。該框架把TCP
和非TCP定義為IP之上的兩個傳輸類。本規范將IP/UDP/TCP從非TCP類中抽取出來創建為第三
類。
2. 設想和折中
   本壓縮方案的目標是，在不發送UDP校驗和的情況下，將大多數包的IP/UDP/RTP頭壓縮到
2個字節，在帶校驗和時則壓縮到4個字節。這一方案的提出主要是受使用14.4kb/s和
28.8kb/s撥號調制解調器發送音視頻時遇到的相關問題所引起。這些鏈路提供全雙工通信，
所以協議利用了這點，盡管協議在用于單工鏈路時可能性能會有所下降。該方案在本地鏈路
上往返時間(RTT)很低，從而實現性能最高。
   為了降低低速鏈路下的延遲，除了在第四節中確定了分片和壓縮中可能使用的一些交互
外，本規范并未提出大型數據包的分片和占先策略。分片方案可能會單獨定義并與本壓縮方
案配合使用。
   應該注意到，實現的簡單性是評價壓縮方案的一個重要因素。通信服務器可能要用一個
處理器支持多達100個撥號調制解調器的數據壓縮。因此，如下的考慮都是比較恰當的，即
在設計階段為了實現簡單而犧牲一些通用性，或者在設計上靈活通用但為了簡單性可對設計
進行子集化。通過在壓縮和解壓器之間用更復雜的模型通信改變頭字段還可以達成更好的壓
縮效果，但其復雜性卻是沒必要的。下一節將討論這里列出的一些折中方案。
2.1. 單工與全雙工
   在沒有其它限制的情況下，單工鏈路上的壓縮方案應成為首選。但為防止錯誤發生，單
工鏈路上的操作需要用一個含有壓縮狀態信息的未壓縮包頭進行周期性的刷新。如果明顯的
錯誤信號可以返回，則恢復延遲也可以實質性地縮短，無錯誤情況的開銷也會降低。為了實
現這些性能的優化，本規范包括了一個可逆向發送的明顯錯誤指示。
   在單工鏈路中，可以使用周期性刷新來取代。解壓器一旦偵測到錯誤存在于某個特定的
流中，它可以簡單地放棄該流中所有的包直到接收到一個未壓縮的頭為止，然后繼續解壓。
其致命弱點在于可能要在恢復解壓前要放棄大量的包。周期性刷新的方法在[3]的3.3節中進
行描述，它應用于單工鏈路的IP/UDP/RTP壓縮，或者應用于其它非TCP包流的高延遲鏈路。
2.2. 分片與分層
   在低速鏈路上發送大型數據包所需時間而導致的延遲對于單向音頻應用不算什么大問
題，因為接收方可以適應延遲變動。但對于交互式的交談，最小端到端延遲是非常關鍵的。
對大的，非實時數據包進行分片以允許小的實時包在分片間隙進行傳送可以降低這種延遲。
   本規范只處理壓縮，并且假定，如果包括分片，也將被處理為一個單獨層。將分片和壓
縮按這種方式進行集成并不可取，因為一旦如此，在沒有必要或不可能進行分片的情況下，
連壓縮都不能使用。類似地，應該避免預留協議的任何需求。除了要求鏈路層提供一些包類
型碼，一個包長度指示和良好的錯誤檢測外，該壓縮方案可獨立于任何其它機制而應用在本
地鏈路的兩端。
   相反，單獨對IP/UDP和RTP層進行壓縮丟失了太多的壓縮效率，這些效率可以通過將它們
一起對待而得到。由于相同的函數可以應用于所有層，實現跨越這些協議層邊界的方案是恰
當的。
3.壓縮算法
   本文定義的壓縮算法主要利用了RFC 1144[2]描述的TCP/IP頭壓縮的設計。讀者可以參考
該RFC獲取更多的關于對包頭進行壓縮的基本動機和通用原理。
3.1.基本概念
   對TCP頭壓縮的研究發現，IP和TCP頭有一半的字節在整個連接期間保持不變，這正是降
低數據率的兩個要素中的首要因素。因此，在發送一次未壓縮頭之后，可以將這些字段從其
后的壓縮頭中除去。其余的壓縮來自對變化字段進行區分編碼以減少長度，以及在通常情況
下根據包長度計算變化而完全刪除掉變化字段。這一長度由鏈路層協議指示。
   對于RTP頭的壓縮也可以采用一些相同的技術。不過最大的收獲在于人們發現，盡管每個
包中總有幾個字節要發生變化，但包與包之間的區別卻是恒定的，因此二次差分為0。在會
話期間，通過維護壓縮與解壓器共享的未壓縮頭與一次差分序列，所需通信的便只有二次差
分為0的指示了。在這種情況下，如果不考慮任何信息丟失，則解壓器在收到一個壓縮包后
可以通過將一次差分結果加到保存的未壓縮頭來重建原始包頭。象TCP/IP頭壓縮為多個同時
的TCP連接維護一個共享狀態一樣，IP/UDP/RTP壓縮也應該為多個會話環境維護狀態。一個
會話環境是由IP源地址和目的地址，UDP源端口和目的端口，以及RTP的SSRC字段定義。解壓
器在實現時可以對這些字段使用哈希函數來檢索存儲的會話環境列表。壓縮包攜帶一個稱為
會話環境標識符或者CID的小整數來指示該包應該解釋到哪個環境中。解壓方可以使用CID
直接在存儲的環境列表中來進行檢索。
   由于RTP壓縮是無損壓縮，它可應用于任何可從中受益的UDP通信。當然最可能的例子就
是RTP包，不過也可以使用試探法來判斷一個包是否為RTP包，因為即便試探法給出的答案是
錯的也不會造成什么損害。這樣做需要對所有的UDP包或者至少對偶數端口號的包(見3.4節)
執行壓縮算法。
   為了避免將來無謂地重試，大多數壓縮器在實現時都要維護包流的一個“拒絕緩存”來
記錄那些多次作為RTP包嘗試而壓縮失敗的包。壓縮失敗往往意味著潛在的RTP包頭中一些在
多數時間應保持恒定字段卻發生了變化，如負載類型字段。即便其它類似的字段都保持不變，
為了避免耗盡所有的可用會話環境，一個SSRC字段不斷改變的包流也應放入拒絕緩存。拒絕
緩存可通過源IP地址和目的IP地址以及UDP端口對進行索引，而SSRC字段因為可能發生變化
不能用來作為索引。當RTP壓縮失敗，IP和UDP頭仍然可以被壓縮。分片后不是初始片的IP
包和長度不夠容納一個完整UDP頭的包都不能作為FULL_HEADER發送。另外，沒有容納至少12
字節UDP數據的包也不能用于創建RTP環境。如果這樣的包作為FULL_HEADER包發送，它后面
可以跟隨COMPRESSED_UDP包但不能跟隨COMPRESSED_RTP包。
3.2 RTP數據包頭壓縮
   在IPv4包頭中只有總長度，包ID和校驗和字段會發生改變。因為在鏈路層已經提供了長
度，這里總長度是冗余的，同時由于本壓縮方案必須依靠鏈路層實現良好的錯誤檢測（如PPP
的CRC[4]），頭校驗和也可以省略掉。于是只剩下了包ID，而在假定沒有IP分片的情況下它
也無參加通信。不過為了保持無損壓縮，包ID的變化也將被傳輸。對每個包而言，包ID通常
每次加1或者一個很小的整數值。（有些系統中包ID的增量為交換的字節數，這對壓縮效率
有一些輕微的影響。）而IPv6包頭既沒有包ID字段，也沒有頭校驗和字段，只有負載長度字
段會發生變化。
   由于在IP層和鏈路層均有相應字段，UDP頭中的長度字段也是冗余的。如果選擇不產生UDP
校驗和則UDP的校驗和字段為常數0。否則必須對校驗和進行交互通信以保證無損壓縮。一個
重要原則就是為需要的應用程序維護端到端的錯誤檢測。
   在RTP頭中，作為特定環境標識的一部分，給定的環境的SSRC標識符是恒定不變的。對大
多數包而言，只有順序號和時間戳是因包而異的。如果沒有包丟失或者亂序，順序號應按步
進值1逐包改變。對音頻包，時間戳應按采樣周期增加。對于視頻，時間戳在每幀的第一個
包是發生改變，而在后面該幀的其它包中保持不變。如果每個視頻幀只占據一個包，且視頻
幀按照恒定的速率產生，則幀與幀之間時間戳的變化也是恒定的。
注意到每當這種情況出現，順序號和時間戳字段的二次差分均為0，所以下一個包頭的相應
字段值可通過前一個未壓縮包頭的該字段加上存在會話環境一次差分值得到。當二次差分不
為0時，變化量通常也要遠小于字段中所有位的數目，所以可通過對新的一次差分進行編碼
并傳輸該編碼來達到壓縮的目的，不用傳輸絕對值。
   一個音頻會話峰(talkspurt)中M位將在第一個包中設置，而一個視頻幀中M位在最后一個
包中設置。如果它作為一個常量字段則每次變化都要發送整個RTP頭，如此會造成壓縮效率
明顯下降。因此，壓縮頭中的一位將明確地攜帶M位。如果包通過RTP混合器流動，特別是音
頻數據，則CSRC列表和CC記數將發生改變。但CSRC列表將在會話峰期間保持不變，所以它只
需在發生變化時才發送。
3.3協議
   壓縮協議必須維護一個狀態牢靠的壓縮器和解壓器的共享信息集合。對每個IP/UDP/RTP
包流都有一個單獨的通過源地址IP，目的地址IP，UDP端口對和RTP SSRC字段組合定義的會
話環境。要維護的會話環境數目可通過雙方協商而定。每個環境通過一個8位或者16位的標
識符來標識，具體范圍要根據協商的環境數量決定，所以最大值為65536。未壓縮和壓縮的
包都必須攜帶環境ID和一個4位的用來檢測包通信中丟失的順序號。每個環境都有自己的順
序號空間，所以單個包的丟失只會影響到一個環境。
   每個環境共享的信息包括如下項目
?	完整的IP, UDP和RTP頭，對最后一個由壓縮器發送或者解壓器重建的包，可能還
包括CSRC表。
?	IPv4 ID字段的一次差分結果，當收到環境中的一個未壓縮IP頭時初始化為1，每
次收到一個壓縮包中的delta IPv4 ID字段時更新。
?	RTP時間戳字段的一次差分結果，當收到環境中的一個未壓縮IP頭時初始化為0，
每次收到一個壓縮包中的delta RTP時間戳字段時更新。
?	最后一個4位順序號，用來檢測雙方通信時的包丟失情況。
?	IPv6（見[3]）UDP包的非差分編碼當前產生號。對于IPv4，如果沒有使用下面定
義的COMPRESSED_NON_TCP包類型，則產生號可設置為0。
?	一個經過雙方協商，可選的環境相關的delta編碼表(見3.3.4節)。
   為了在不同的壓縮和解壓器形式下進行通信，本協議依靠鏈路層為除IPv4和IPv6外的四
種新的包格式提供指示：
      FULL_HEADER – 傳送未壓縮IP頭和任何用來在解壓方為特定環境建立未壓縮頭狀態
的后續頭和數據。FULL_HEADER包也攜帶了8或16位的會話環境標識符和4位的順序號用來建
立雙方的同步。格式見3.3.1節。
      COMPRESSED_UDP – 傳送壓縮到6字節或更少字節(如禁用UDP校驗和則通常為2字節)
的IP和UDP頭，后面是任何未壓縮形式的后續頭(可能為RTP)和數據。當RTP頭的常量字段有
所不同時才使用包類型。RTP包頭包括一個會變化的SSRC字段值，所以可能重定義會話環境。
其格式在3.3.3節定義。
      COMPRESSED_RTP – 表示RTP頭和IP及UDP頭一起壓縮。該頭的大小可以是2個字節，或
者當需要傳送變化時更多一些。當二次差分值(至少在通常的常量字段)為0時使用包類型。
它包括delta編碼，它是為了能在未壓縮RTP頭發送后并當改變發生時對于那些變化字段建立
一次差分隊列。其格式在3.3.2中定義。
      CONTEXT_STATE – 一種由解壓器發送給壓縮器的特殊包，用來傳輸已經或者可能已經
失去同步的環境ID。該包僅通過點到點鏈路發送，所以它不需要IP頭。其格式在3.3.5中定
義。
   當本壓縮方案作為通用頭壓縮框架[3]的一部分用于IPv6時，還可使用另一種包類型：
      COMPRESSED_NON_TCP –無須進行差分編碼傳輸[3]定義的壓縮IP/UDP包。如果用于
IPv4，為了能攜帶IPv4 ID字段，它比前面所講的COMPRESSED_UDP要多用1到2個字節。而IPv6
沒有ID字段，這種非差分壓縮在包丟失時更有彈性。
   在PPP協議[4]中為這些包格式分配代碼應由IANA決定。
3.3.1.  FULL_HEADER (未壓縮) 包格式
   此處定義的FULL_HEADER和[3]中所給出的定義是一致的。在那里有關于各種方案的
完整設計細節。它在IPv4中通常就是一個IP頭，后面接著是一個UDP頭和UDP負載（可能為一