本備忘錄的狀態
本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建議以
得到改進。請參考最新版的“Internet正式協議標準”(STD1)來獲得本協議的標準化程度
和狀態。本備忘錄的發布不受任何限制。
版權聲明
Copyright(C)TheInternetSociety(1999).AllRightsReserved.
摘要
本文描述了一種對ip/UDP/RTP數據報頭進行壓縮的方法，它可以降低在低速串行鏈路上
的網絡開銷。多數情況下，三個頭可壓縮到2-4字節。
請賜教并將您的建議發送到工作組郵件列表rem-conf@es.net或直接給作者。
本文中的要害字“必須”，“必須不”，“要求的”，“應該”，“不應該”，“會”，“不會”，
“建議”，“或許”，“可選的”在RFC2119中解釋。
目錄
本備忘錄的狀態 1
版權聲明 1
摘要 1
1.介紹 2
2.設想和折中 2
2.1.單工與全雙工 3
2.2.分片與分層 3
3.壓縮算法 3
3.1.基本概念 3
3.2RTP數據包頭壓縮 4
3.3協議 5
3.4.RTCP控制包壓縮 12
3.5.非RTPUDP包壓縮 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.壓縮算法
本文定義的壓縮算法主要利用了RFC1144[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.2RTP數據包頭壓縮
在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端口對和RTPSSRC字段組合定義的會
話環境。要維護的會話環境數目可通過雙方協商而定。每個環境通過一個8位或者16位的標
識符來標識，具體范圍要根據協商的環境數量決定，所以最大值為65536。未壓縮和壓縮的
包都必須攜帶環境ID和一個4位的用來檢測包通信中丟失的順序號。每個環境都有自己的順
序號空間，所以單個包的丟失只會影響到一個環境。
每個環境共享的信息包括如下項目
? 完整的IP,UDP和RTP頭，對最后一個由壓縮器發送或者解壓器重建的包，可能還
包括CSRC表。
? IPv4ID字段的一次差分結果，當收到環境中的一個未壓縮IP頭時初始化為1，每
次收到一個壓縮包中的deltaIPv4ID字段時更新。
? RTP時間戳字段的一次差分結果，當收到環境中的一個未壓縮IP頭時初始化為0，
每次收到一個壓縮包中的deltaRTP時間戳字段時更新。
? 最后一個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，為了能攜帶IPv4ID字段，它比前面所講的COMPRESSED_UDP要多用1到2個字節。而IPv6
沒有ID字段，這種非差分壓縮在包丟失時更有彈性。
在PPP協議[4]中為這些包格式分配代碼應由IANA決定。
3.3.1.FULL_HEADER(未壓縮)包格式
此處定義的FULL_HEADER和[3]中所給出的定義是一致的。在那里有關于各種方案的
完整設計細節。它在IPv4中通常就是一個IP頭，后面接著是一個UDP頭和UDP負載（可能為一
個RTP頭及其負載）。不過，FULL_HEADER也可以攜帶IP封裝的包，其中可能有兩個IP頭
及其相應的UDP和RTP。對于IPv6，該包還可能是IPv6和IPv4頭的組合。通常每個后續頭都
由前一個頭的類型字段來指示。
FULL_HEADER包與IPv4或IPv6包的區別在于它必須攜帶壓縮環境ID和4位的順序號。為了
避免頭變大，這些值被插入到IP和UDP頭的長度字段中，因為實際的長度可以根據鏈路層提
供的長度推算出來。這里需要2個16位長的字段：它們來自包中的頭兩個可用頭。對于
IPv4/UDP包，第一個長度字段是IP頭總長度字段，第二個字段是UDP頭長度字段。對于IPv4
封裝包，第一個長度字段為第一個IP頭的總長度字段，第二個字段是第二個IP頭的總長度字
段。
如5.3.2節所規定，環境ID(CID)和4位順序號的位置取決于是采用8位還是16位環境ID，
如下圖所示(16位寬，左邊為最高位)：
對于8位環境ID:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
01GenerationCID第一長度字段
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0seq第二長度字段
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
對于16位環境ID:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11Generation0seq第一長度字段
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CID第二長度字段
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
第一長度字段的起始位表示CID的長度。CID的長度要么對于所有環境均相同，要么必須
提供兩個額外包類型來分別指示COMPRESSED_UDP和COMPRESSED_RTP包格式采用8位還是16位
CID。對于IP/UDP/RTP壓縮方案，第一長度字段的第二位為1表示當前為4位順序號。
在IPv6的COMPRESSED_NON_TCP包中使用Generation字段方法如[3]所述。IPv4實現不使用
COMPRESSED_NON_TCP包，壓縮器應該將generation字段設置為0。為了使IPv4和IPv6操作一
致，當解壓器接收到Generation值后就將它存在環境中，并在CONTEXT_STATE包中返回最近
的值。
當接收到一個FULL_HEADER時，接收方將整個頭存在由環境ID選擇的環境中。4位順序號
也存在環境中，從而可實現解壓器和壓縮器的同步。在使用COMPRESSED_NON_TCP包時，順序
號插入到該包的“Data字段”中，并且D位設置參照[3]的第6節所述。在接收到
COMPRESSED_NON_TCP包后，接收方將Generation號和存在環境中的值進行比較。假如不同，
則環境已經過期，需要用該FULL_HEADER包來進行刷新。假如一致，則壓縮的IP和UDP頭信息，
順序號，以及RTP頭都存入已保存的環境中。
保存環境所需要的內存數量取決于FULL_HEADER中到底封裝了多少個頭。最大頭的大小可
通過壓縮/解壓縮雙方協商得到。
3.3.2.COMPRESSED_RTP包格式
假如包中RTP頭的二次差分值為0，則解壓器只需在前一個包的未壓縮頭上加上存儲的一
次差分值就可以重建該包。雙方之間只需傳輸會話環境標識符和順序號就可以維持同步和檢
測出丟失包。
假如包中RTP頭某些字段的二次差分值不為0，則要在雙方要傳輸這些字段的新的一次差
分結果的壓縮編碼。除了要把新的一次差分值加到解壓器會話環境的未壓縮頭上，也要加到
那些二次差分為0的后續包的相應字段上并顯式地存儲到環境里。每當一次差分改變時，都
要對其進行傳輸和存儲。在實際應用中，唯一需要用到一次差分的字段就是IPv4ID字段和
RTP時間戳字段。
RTP順序號字段的增量為1。假如順序號變化不是1，則必須進行通信以報告該區別，但并
不因此為下一個包重新設置期望的變化值。期望的一次差分值仍然為1，這樣假如下一個包
按順序來到就不用再為變化進行通信。
對于RTP時間戳，當發送FULL_HEADER,COMPRESSED_NON_TCP和COMPRESSED_UDP包刷新RTP
狀態時，存儲的一次差分初始化為0。假如下一個包的時間戳一樣(如相同的視頻幀)，則二
次差分值為0。否則必須將兩個包時間戳的差別作為新的一次差分傳輸并存入環境中，該值
將被加到解壓器環境存儲的未壓縮頭時間戳上。每當后續包的一次差分改變時，都要用該變
化來更新環境。
類似地，由于IPv4ID字段每次遞增1，當用FULL_HEADER刷新狀態或以非壓縮形式發送攜
帶ID字段的COMPRESSED_NON_TCP包時，該字段的一次差分初始化為1。然后，每當一次差分
改變其變化都會重傳并存到環境中。
這里還用了一個掩蔽碼來表示哪個字段發生了非預期變化。除了小鏈路順序號外，要在
壓縮的IP/UDP/RTP頭中進行傳輸的項列表如下：
I=IPv4包ID(非IPv4頭為常數0)
U=UDP校驗和
M=RTP標志位
S=RTP順序號
T=RTP時間戳
L=RTPCSRC記數和列表
假如用4位作為鏈路順序號來進行丟失檢測，包頭中就沒有足夠的位逐一分配給上面的幾
項并填充到一個單字節中隨環境ID發送。
因為發送源要么在會話中所有的包里包括UDP校驗和，要么就根本不用校驗和，所以沒必
要顯式地攜帶U位表示UDP校驗和的存在。假如以未壓縮包頭初始化會話狀態時其校驗和非0，
就說明在所有的后續壓縮包中都將插入16位的未編碼校驗和，直到發送了另一個未壓縮包改
變該設置。對于剩余的幾項，用于CSRC記數和列表的L位可能是使用頻率最低的。與其專門
在掩蔽碼中用一位來表示CSRC改變，還不如采用另外一種不常用的位組合。該位組合稱為
MSTI。假如IP包ID，RTP標志位，RTP順序號和RTP時間戳的位都已經被使用，這種非凡情況
表示其后可能有一種擴展形式的壓縮RTP包頭。該包頭將包括一個額外字節，其中含有4位加
上CC記數的實際值。當CSRC列表（長度由CC記數表示）出現在未壓縮RTP頭中時也將被包含
其中。
假設RTP頭中的其余字段(版本,P位,X位,負載類型和SSRC標識符)都保持相對恒定。
非凡地，對于給定的環境SSRC標識符定義為常量，因為SSRC標識符是選擇環境的一個因素。
假如任何其它字段發生變化，都必須按照3.3.3節要求發送未壓縮RTP包。
下圖中，帶點劃線的壓縮IP/UDP/RTP頭表示可選字段。最高位為0。多字節字段按照網絡
字節順序發送(最高字節在先)。Delta字段通常如圖所示為單字節，但根據具體delta值也可
能為2或3字節，如3.3.4節所解釋。
01234567
+...............................+
:會話環境ID的msb:(假如使用16位CID)
+-------------------------------+
會話環境ID的lsb
+---+---+---+---+---+---+---+---+
MSTI鏈路順序號
+---+---+---+---+---+---+---+---+
::
+UDP校驗和+(假如環境中校驗和為非0)
::
+...............................+
::
+"RANDOM"fields+(假如被封裝)
::
+...............................+
:M'S'T'I'CC:(假如MSTI=1111)
+...............................+
:deltaIPv4ID:(假如I或I'=1)
+...............................+
:deltaRTP順序號:(假如S或S'=1)
+...............................+
:deltaRTP時間戳:(假如T或T'=1)
+...............................+
::
:CSRClist:(假如MSTI=1111
::并且CC非0)
::
+...............................+
::
:RTP頭擴展:(假如環境中設置了X位)
::
::
+-------------------------------+

RTP數據
//
//

+-------------------------------+
:填充:(假如環境中設置了P位)
+...............................+
假如FULL_HEADER初始化的環境中IPv4頭數目多余1，則封裝頭的IPID字段必須如[3]所
述按照絕對值形式發送。這些字段標識為"RANDOM"字段。它們按照與原始包中相同的順序被
插入COMPRESSED_RTP包，如圖所示，其后緊接著是UDP校驗和或MSTI字節。除非IPv4包正好
在UDP頭之前，該頭的IPID才會被區別發送，例如，假如二次差分為0，或者二次差分不為0
但該字段是作為deltaIPv4ID字段它就不占任何位。假如沒有IPv4頭正好位于UDP頭之前，
則I位必須為0且不應存在deltaIPv4ID字段。
3.3.3.COMPRESSED_UDP包格式
假如RTP頭中任何一般情況下應為常量的字段（如負載類型字段）發生了變化，則必須發
送一個非壓縮RTP頭。假如IP和UDP頭不需要更新，則該RTP頭可以用COMPRESSED_UDP包攜帶，
而不必用FULL_HEADER包。除了M,S和T為為常數0以及沒有相應的delta字段以外，
COMPRESSED_UDP包同COMPRESSED_RTP格式相同：
01234567
+...............................+
:會話環境ID的msb:(假如使用16位CID)
+-------------------------------+
會話環境ID的lsb
+---+---+---+---+---+---+---+---+
000I鏈路順序號
+---+---+---+---+---+---+---+---+
::
+UDP校驗和+(假如環境中校驗和非0)
::
+...............................+
::
+"RANDOM"字段+(假如被封裝)
::
+...............................+
:deltaIPv4ID:(假如I=1)
+-------------------------------+
UDP數據
:(非壓縮RTP):
請注重，這里IP/UDP頭的壓縮形式和[3]中定義的COMPRESSED_NON_TCP包類型不同。其目
的是象IPv4所答應的那樣，當禁用UDP校驗和時使壓縮目標達到2字節。[3]中定義的協議沒
有使用UDP包的差分編碼，所以在用于IPv4時，除了前面的兩個壓縮字節，還有兩個字節的
IPID和兩個字節的非0UDP校驗和都要進行傳輸。對于IPv6,可使用COMPRESSED_NON_TCP包
類型來替代。
3.3.4.差分編碼Encodingofdifferences
COMPRESSED_RTP和COMPRESSED_UDP包的delta字段為變長編碼，可將壓縮數據映射到更多
的通常使用值。下面規定了一種優化的哈夫曼編碼作為缺省編碼，推薦在實現表驅動delta
編/解碼器來為會話進行面向表協商時使用。針對一定范圍內數據的測試表明，在合理的表
規模下基于對位流進行順序解釋的編碼執行速度比非表驅動的實現要快，這種缺省表和哈夫
曼編碼就是例子。缺省delta編碼規范見下表。該編碼在IPID和RTP順序號變化很小的情況
下可高效編碼，此時壓縮器發出的包丟失，但仍能將大多數音視頻deltas保持為2字節。左
邊的列是要編碼的10進制數，右邊的列是16進制顯示的編碼后按發送順序排列(網絡字節順
序)的字節序列。其中顯示了相臨范圍的首尾值，其余均省略：
十進制16進制
-16384C00000
::
-129C03F7F
-1288000
::
-1807F
000
::
1277F
1288080
::
16383BFFF
16384C04000
::
4194303FFFFFF
對于正數，在一個字節內直接以0到127表示。假如該字節的最高兩位是10或者11,則表示
分別表示要擴展到2或3個字節。低6位按照降序同后面緊跟的1到2個字節聯合表示一個14或
22位值。
當包出現亂序或者在MPEG視頻的RTP時間戳故意被打亂時可能會出現負數的delta值。這
種情況很少見，所以負數值編碼范圍更小，僅使用表中正數值剩余的部分。
RTP時間戳值中小于-16384或大于4194303的改變都會導致強制發送未壓縮的
FULL_HEADER,COMPRESSED_NON_TCP或COMPRESSED_UDP類型RTP頭。IPID和RTP順序號字段都
只有16位，所以這些字段的負數delta都掩蔽為16位再進行編碼（作為16位正數）。
3.3.5.錯誤恢復
除了由FULL_HEADER和COMPRESSED_NON_TCP包設置外，當特定環境的4位順序號增量不為1
時，解壓器必須將環境置為無效并發送CONTEXT_STATE包回壓縮器表示環境已經無效。無效
環境的所有當前包都必須丟棄，直到收到一個FULL_HEADER或COMPRESSED_NON_TCP重建穩定
狀態為止（除非使用了本節后面將描述的"twice"算法。）。由于在這一過渡時期可能會有
多個壓縮包到達，解壓器應該為每個收到的壓縮包重新傳輸CONTEXT_STATE包，但應該限制
重傳輸率以避免反向通道的溢出。
當鏈路中出現錯誤時，鏈路層通常將放棄損壞的包，但可以提供一個錯誤指示。在相同
環境的另一個包傳輸前可能會消耗一些時間，然后該包將被解壓器發現亂序而拋棄，造成至
少兩個包丟失。鏈路提供顯示地錯誤指示是為了快速恢復，解壓器可以有選擇地發送一個咨
詢CONTEXT_STATE包為最近的一個或多個活動環境（沒必要為所有環境）列出最近有效的順
序號和generation號。對于給定的環境，假如壓縮器還沒有發送更高順序號的壓縮包，并且
generation號和當前號一致，則不需要任何校正動作。否則壓縮器就得選擇標志環境為無效
以便下一個包以FULL_HEADER或COMPRESSED_NON_TCP模式(假如generation號不一致則需要
FULL_HEADER)發送。不過可以注重到，假如鏈路層RTT時間比包間隙很大，這時已經有多個
不同環境的包沿鏈路發送了，這使得在壓縮器收到CONTEXT_STATE包時順序號可能已經增大。
其結果就是有些環境被沒必要地變為無效，導致額外地消耗了帶寬。
下圖所示為CONTEXT_STATE包的格式。第一個字節是類型碼，答應CONTEXT_STATE包類型
被[3]中定義的通用壓縮框架中的多個壓縮方案共享。包其余部分的內容取決于具體的壓縮
方案。在本文的IP/UDP/RTP壓縮方案中，其余部分組織為一個塊的列表，可以為多個環境指
示狀態，前面為一個字節表示的塊數目。
IP/UDP/RTP壓縮方案中使用了兩個類型碼值。1表示采用8位會話環境:
01234567
+---+---+---+---+---+---+---+---+
1=IP/UDP/RTP如CID為8位
+---+---+---+---+---+---+---+---+
會話計數
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
會話環境ID
+---+---+---+---+---+---+---+---+
I000順序號
+---+---+---+---+---+---+---+---+
00generation
+---+---+---+---+---+---+---+---+
...
+---+---+---+---+---+---+---+---+
會話環境ID
+---+---+---+---+---+---+---+---+
I000順序號
+---+---+---+---+---+---+---+---+
00generation
+---+---+---+---+---+---+---+---+
2表示使用16位的會話環境ID。
會話環境ID按照網絡字節順序發送（最高位優先）：
01234567
+---+---+---+---+---+---+---+---+
2=IP/UDP/RTP如CID為16位
+---+---+---+---+---+---+---+---+
會話數目
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+

+會話環境ID+

+---+---+---+---+---+---+---+---+
I000順序號
+---+---+---+---+---+---+---+---+
00generation
+---+---+---+---+---+---+---+---+
...
+---+---+---+---+---+---+---+---+

+會話環境ID+

+---+---+---+---+---+---+---+---+
I000順序號
+---+---+---+---+---+---+---+---+
00generation
+---+---+---+---+---+---+---+---+
在標志為無效，要發送COMPRESSED_NON_TCP包或FULL_HEADER的環境中，"I"位應設置為1。
假如I為0，則環境處于咨詢狀態。I位設為0表示、在鏈路錯誤指示后要發送環境咨詢狀態。
由于CONTEXT_STATE包本身也可能丟失，所以答應對一個或多個塊重傳輸。但希望只有在接
收到另一個包時才觸發重傳輸，假如鏈路幾乎空閑時，可用一個相對較長的計時器來觸發重
傳輸(如定為1秒)。假如給定環境的塊被重傳輸，它可能與用來刷新環境的FULL_HEADER或
COMPRESSED_NON_TCP錯過。這時壓縮器可以忽略錯誤指示。
在需要傳輸UDP校驗和的情況下，解壓器可以嘗試使用[3]的10.1節描述的"twice"算法。
在該算法中，假設delta值與丟失包和隨后接收的一個包相同則delta要多次應用。校驗和匹
配表示成功。對于這里定義的方案，順序號的區別說明了delta必須要應用的次數。注重，
一個不正確的正指示可能會帶來一些小風險。即便這里"twice"算法應用成功，也建議發送
一個FULL_HEADER或COMPRESSED_NON_TCP包。
有些錯誤可能無法檢測出來，比如一排丟失了16個包且鏈路層沒有提供錯誤指示。在這
種情況下解壓器將產生無效的包。假如UDP校驗和正在傳輸，接收方可能會檢測到無效包并
且丟棄他們，但是接收方無法通知解壓器。因此，建議解壓器周期性地驗證UDP校驗和，如
每16個包驗證一次。假如發現錯誤，它應將環境置為無效并且用一個CONTEXT_STATE包來通
知壓縮器。
3.4.RTCP控制包壓縮
按照RTP協議規定，數據通過偶數端口發送，而RTCP包通過下一個奇數號端口進行發送，
因此可以為RTP和RTCP包分別制定壓縮方案。對于RTCP，壓縮同時針對包頭和數據本身，即
不同包類型的內容。SR和RRRTCP包中的數字內容不好壓縮，但SDES包中的文本信息可以壓
縮到一個屏蔽位表示每個存在并已壓縮的項(用于對SDESNOTE項進行計時并答應端系統為
計算間隔而測量平均RTCP包大小)。
然而由于一些原因（盡管壓縮應該應用于IP和UDP頭），在本壓縮方案中并不對RTCP頭和
數據進行壓縮。RTP協議規范建議應該按比例決定RTCP包間隙，以便所有會話中參與者占用
的RTCP總帶寬不超過5%的會話總帶寬，所以壓縮RTCP并沒有太多的好處。壓縮SDES項會造成
每個環境ID要存儲的共享狀態明顯增加。并且，當通過一個RTP混合器發送多個源的SDES信
息時，為了答應壓縮就必須為每個SSRC標識符維護一個單獨的RTCP會話環境。在一個超過255
個參與者的會話中，即使只有一個參與者發送數據也會造成環境緩存中大量的垃圾數據。假
設RTCP包作為COMPRESSED_UDP形式發送，即使不對其進行壓縮，多數情況下它所占壓縮鏈路
的比重也不超過5%。鑒于非壓縮RTCP包消耗的帶寬不超過會話總帶寬的5%，對于一個長度為
90字節的典型RTCP包，只要RTP數據包負載長度至少為108字節，則RTCP所占用的壓縮帶寬比
率也會不超過5%。假如RTP負載長度比較小，該比率會有所提高，但對于負載大小為37字節
的RTP包而言，該比例仍不會超過7%。假如RTP負載數據包很大，則壓縮RTCP所占的比例小于
非壓縮RTCP（如對1000字節的包該比例為4%）。
3.5.非RTPUDP包壓縮
如前所述，COMPRESSED_UDP包可用來壓縮未攜帶RTP信息的UDP包。UDP之頭后的任何數據
都不太可能象在RTP頭中相應字段一樣有恒定不變的值。非凡地，SSRC字段就很可能發生改
變。因此為了避免當SSRC字段改變時用光環境槽，很有必要明了這些非RTP的UDP包流（由于
該字段是用來標識特定RTP環境的一部分）。每一個這樣的流都可以擁有一個環境，但編碼
器只在環境中設置一個標志來表示SSRC字段的變化可被忽略，且將發送COMPRESSED_UDP包而
非COMPRESSED_RTP包。
4.與分片的交互
為了減少延遲，在連接RTP頭時使用分片的方法對大的非實時包進行分割，以便答應小的
實時包能利用分割間隙進行發送。由于這樣的交錯發送會改變解壓器的接收到的包順序，導
致錯誤出現，我們在此均假定這些大數據包對于壓縮器到解壓器的通道是旁路的。頭壓縮對
大數據包而言并不重要，因為其開銷所占比重較小。
假如有些來自RTP會話環境的包被選中參加分片(主要取決于大小)，而另一些不參加分
片，則可能造成亂序的現象出現。這將導致壓縮效率的下降，因為在順序空間中這些被分割
的大包會被當作是丟失。但是，由于RTP順序號將在接收方被正確重建且答應應用程序進行
重排序，所以暫時的亂序也不會造成過于嚴重的問題。就象鏈路層自己能檢測到的鏈路錯誤
一樣，分片機制使用順序信息檢測到的鏈路錯誤可以通過一個CONTEXT_STATE消息指示給壓
縮器。
環境ID字節位于COMPRESSED_RTP頭的最前面，假如這樣可行并經過協商，可以把該字節
分派給分片層。由于壓縮器可以強制分配環境ID，其值可設置為和分片層中的環境標識符一
致。
5.壓縮協商
在特定鏈路上使用IP/UDP/RTP壓縮屬于鏈路層協議的功能。所以要為具體協議單獨定義
協商方式，如為PPP[4]。下面是可能要協商的項：
? 環境ID的大小。
? 環境中包頭棧的最大值。
? 一個對delta值解碼的環境相關表。
6.致謝
很多朋友都為本壓縮方案的設計和相關問題的解決付出了努力。1996年3月，Scott
Petrack在落山磯的AVT工作組發起了關于RTP頭壓縮的討論。CarstenBormann開發了低速鏈
路上帶傳輸控制的壓縮體系結構，同時對于本文描述的方案也作出了一些非凡貢獻。David
Oran獨立開發了一個基于本文類似思想的Note，并建議使用PPP多鏈路協議進行分片。Mikael
Degermark在把本方案同IPv6壓縮框架進行集成方面作出了貢獻。
7.參考文獻
[1]Schulzrinne,H.,Casner,S.,Frederick,R.andV.Jacobson,"RTP:
ATransportProtocolforreal-timeapplications",RFC1889,
January1996.
[2]Jacobson,V.,"TCP/IPCompressionforLow-SpeedSerialLinks",
RFC1144,February1990.
[3]Degermark,M.,Nordgren,B.andS.Pink,"HeaderCompressionfor
IPv6",RFC2507,February1999.
[4]Simpson,W.,"ThePoint-to-PointProtocol(PPP)",STD51,RFC
1661,July1994.
[5]Hoffman,D.,Fernando,G.,Goyal,V.andM.Civanlar,"RTP
PayloadFormatforMPEG1/MPEG2Video",RFC2250,January1998.
8.安全性考慮
由于加密會消除本壓縮方案所試圖實現的冗余性，所以為了在低帶寬鏈路上完成操作我們考
慮可能要放棄加密。不過對于那些需要壓縮數據而不是包頭的情況，RTP已經規定了另一種可選
的加密方法，它只壓縮RTP負載而將包頭保持明文。這樣壓縮依然可以使用。
一個有問題的或是惡意的壓縮器可能使解壓器重組的包同原始包不一致卻有有效的IP,IDP，
RTP頭，甚至有效的UDP校驗和。這樣的破壞可通過端到端認證和完整性機制（它不會受到壓縮的
影響）檢測出來。認證頭中的恒定部分可通過[3]所描述的方法進行壓縮。
本協議在發送CONTEXT_STATE控制包時沒有執行任何認證。有權訪問壓縮器和解壓器之間鏈路
的攻擊者可以通過插入錯誤的包使壓縮效率下降，甚至導致鏈路擁塞。不過他們還可以通過許多
其他方式來破壞通信。假如使用的壓縮技術會造成接收端計算負荷不均衡，系統就有潛在拒絕服
務式攻擊的威脅。攻擊者可通過插入病態報文造成解壓縮復雜性增加，導致接收端過載和處理其
它流的效率降低。然而，本壓縮方案并未顯示出有任何明顯的波動性。
對本協議的安全性回顧并沒有發現任何多余的安全性考慮。
9.作者地址
StephenL.Casner
CiscoSystems,Inc.
170WestTasmanDrive
SanJose,CA95134-1706
UnitedStates
EMail:casner@cisco.com
VanJacobson
CiscoSystems,Inc.
170WestTasmanDrive
SanJose,CA95134-1706
UnitedStates
EMail:van@cisco.com
10.版權聲明
Copyright(C)TheInternetSociety(1999).AllRightsReserved.
Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseeXPlainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsUChcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurpoSEOf
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.
Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.