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


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


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

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