技術簡介
IP包頭過長是影響其在無線網路中套用的一個重要問題，解決這一問題的方案是採用頭部壓縮技術CRTP（RFC2508，低速串列鏈路下IP/UDP/RTP數據包頭的壓縮）。CRTP的主要設計目標是在不傳送UDP校驗和的情況下，將大多數包的IP/UDP/RTP頭壓縮到2個位元組，在帶校驗和時則壓縮到4個位元組。這一方案的提出主要是受使用14.4kb/s和28.8kb/s撥號數據機傳送音視頻時遇到的相關問題所引起。這些鏈路提供全雙工通信，所以協定利用了這點，儘管協定在用於單工鏈路時可能性能會有所下降。該方案在本地鏈路上往返時間(RTT)很低，從而實現性能最高。
技術原理
頭部壓縮技術的原理是：語音編碼器生成的語音數據被逐層封裝成RTP，UDP和IP包。這樣的語音幀頭部長度達到40個位元組，但是有效載荷只有15～30個位元組。這樣對於一個相的語音流來說，在連續的語音包中就有較高的冗餘度。要降低這種冗餘，必須使用壓縮算法。CRTP可以將40位元組的包頭最小壓縮至2位元組。用CRTP進行頭部壓縮，必須維護上下文信息（Context，即未壓縮的在通路兩端上一次傳送的包頭），這樣，頭部僅僅攜帶上下文信息的變化即可。但是如果發生丟包或包被損壞，接收端就無法正確地更新上下文信息。所以必須提供相應的機制去監測上下文錯誤並去修復它。CRTP可以傳送上下文更新請求來修復上下文，但是鏈路上的往返時間會影響這種修復機制的效率。圖1就是這種壓縮標準的一個示意圖。一般來說，IP/UDP/RTP頭中有一半的位元組在整個連線期間保持不變，儘管每個包中總有幾個位元組要發生變化，但包與包之間的區別卻是恆定的，也就是說二次差分為0。因此，可以在傳送一次未壓縮頭之後，將未變化的欄位從其後的壓縮頭中除去。其餘的壓縮內容來自變化欄位，可以對變化的欄位進行區分編碼以減少壓縮後的長度，以及在通常情況下根據包長度計算變化而完全刪除掉的變化欄位，在會話期間，這一長度由鏈路層協定指示。通過維護壓縮與解壓設備共享的未壓縮頭與一次差分序列，所需通信的便只有二次差分為0的指示了。在這種情況下，如果不考慮任何信息丟失，則解壓設備在收到一個壓縮檔後可以通過將一次差分結果加到保存的未壓縮頭來重建原始包頭。像TCP/IP頭壓縮為多個同時的TCP連線維護一個共享狀態一樣，IP/UDP/RTP壓縮也應該為多個會話環境維護狀態。一個會話環境是由IP源地址和目的地址、UDP源連線埠和目的連線埠、以及RTP的SSRC欄位定義。解壓設備可實時的對這些欄位使用哈希函式來檢索存儲的會話環境列表。壓縮檔攜帶一個稱為會話環境標識符或者CID的小整數來指示該包應該解壓到哪個環境中。解壓方可以使用CID直接在存儲的環境列表中來進行檢索。由於RTP壓縮是無損壓縮，它可套用於任何可從中受益的UDP通信。當然最可能的例子就是RTP包，不過也可以使用試探法來判斷一個包是否為RTP包，因為即便試探法給出的答案是錯的也不會造成什麼損害。這樣做需要對所有的UDP包執行壓縮算法。
為了避免將來無謂地重試，大多數壓縮設備在實現時都要維護包流的一個“拒絕快取”來記錄那些多次作為RTP包嘗試而壓縮失敗的包。壓縮失敗往往意味著潛在的RTP包頭中一些在多數時間應保持恆定欄位卻發生了變化，如負載類型欄位。即便其它類似的欄位都保持不變，為了避免耗盡所有的可用會話環境，一個SSRC欄位不斷改變的包流也應放入拒絕快取。拒絕快取可通過源IP位址和目的IP位址以及UDP連線埠對進行索引，而SSRC欄位因為可能發生變化不能用來作為索引。當RTP壓縮失敗，IP和UDP頭仍然可以被壓縮。分片後不是初始片的IP包和長度不夠容納一個完整UDP頭的包都不能作為FULL_HEADER傳送。另外，沒有容納至少12位元組UDP數據的包也不能用於創建RTP環境。如果這樣的包作為FULL_HEADER包傳送，它後面可以跟隨COMPRESSED_UDP包，但不能跟隨COMPRESSED_RTP包。
壓縮欄位
在IPv4包頭中只有總長度，包ID和校驗和欄位會發生改變。因為在鏈路層已經提供了長度，這裡總長度是冗餘的，同時由於CRTP必須依靠鏈路層實現良好的錯誤檢測（如PPP的CRC），頭校驗和也可以省略掉。於是只剩下了包ID，而在假定沒有IP分片的情況下它也不參加通信。不過為了保持無損壓縮，包ID的變化也將被傳輸。對每個包而言，包ID通常每次加1或者一個很小的整數值。由於在IP層和鏈路層均有相應欄位，UDP頭中的長度欄位也是冗餘的。如果選擇不產生UDP校驗和則UDP的校驗和欄位為常數0。否則必須對校驗和進行互動通信以保證無損壓縮。一個重要原則就是為需要的應用程式維護端到端的錯誤檢測。
在RTP頭中，作為特定環境標識的一部分，給定的環境的SSRC標識符是恆定不變的。對大多數包而言，只有順序號和時間戳是因包而異的。如果沒有包丟失或者亂序，順序號應按步進值1逐包改變。對音頻包，時間戳應按採樣周期增加。對於視頻，時間戳在每幀的第一個包是發生改變，而在後面該幀的其它包中保持不變。如果每個視頻幀只占據一個包，且視頻幀按照恆定的速率產生，則幀與幀之間時間戳的變化也是恆定的。注意到每當這種情況出現，順序號和時間戳欄位的二次差分均為0，所以下一個包頭的相應欄位值可通過前一個未壓縮檔頭的該欄位加上存在會話環境一次差分值得到。當二次差分不為0時，變化量通常也要遠小於欄位中所有位的數目，所以可通過對新的一次差分進行編碼並傳輸該編碼來達到壓縮的目的，不用傳輸絕對值。
一個音頻會話峰(talkspurt)中M位將在第一個包中設定，而一個視頻幀中M位在最後一個包中設定。如果它作為一個常量欄位則每次變化都要傳送整個RTP頭，如此會造成壓縮效率明顯下降。因此，壓縮頭中的一位將明確地攜帶M位。如果包通過RTP混合器流動，特別是音頻數據，則CSRC列表和CC記數將發生改變。但CSRC列表將在會話峰期間保持不變，所以它只需在發生變化時才傳送。
壓縮協定
壓縮協定必須維護一個狀態牢靠的壓縮方和解壓方的共享信息集合。對每個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位順序號，用來檢測雙方通信時的包丟失情況。
IPv6UDP包的非差分編碼當前產生號。對於IPv4，如果沒有使用下面定義的COMPRESSED_NON_TCP包類型，則產生號可設定為0。
一個經過雙方協商，可選的環境相關的delta編碼表。
為了在不同的壓縮和解壓方形式下進行通信，本協定依靠鏈路層為除IP包外的四種新的式提供指示：
FULL_HEADER–傳送未壓縮IP頭和任何用來在解壓方為特定環境建立未壓縮頭狀態的後續頭和數據。FULL_HEADER包也攜帶了8或16位的會話環境標識符和4位的順序號用來建立雙方的同步。
COMPRESSED_UDP–傳送壓縮到6位元組或更少位元組(如禁用UDP校驗和則通常為2位元組)的IP和UDP頭，後面是任何未壓縮形式的後續頭(可能為RTP)和數據。當RTP頭的常量欄位有所不同時才使用包類型。RTP包頭包括一個會變化的SSRC欄位值，所以可能重定義會話環境。
COMPRESSED_RTP–表示RTP頭和IP及UDP頭一起壓縮。該頭的大小可以是2個位元組，或者當需要傳送變化時更多一些。當二次差分值(至少在通常的常量欄位)為0時使用包類型。它包括delta編碼，它是為了能在未壓縮RTP頭髮送後並當改變發生時對於那些變化欄位建立一次差分佇列。
CONTEXT_STATE–一種由解壓方傳送給壓縮方的特殊包，用來傳輸已經或者可能已經失去同步的環境ID。該包僅通過點到點鏈路傳送，所以它不需要IP頭。
2.4RTCP控制包處理
呼叫建立一般使用實時信道建立控制協定（RTCP）來建立信道，傳輸Q.931信令。由於可以按比例決定RTCP包間隙，可以使所有會話中參與者占用的RTCP總頻寬不超過5%的會話總頻寬，所以建議對RTCP包不做壓縮處理。
3套用舉例上圖是CRTP的一個典型套用場景。無線鏈路原來都是通過ATM/TDM進行承載，現在將會向IP化的方向發展，使用IP進行承載可以大大降低目前對於傳輸的需求，但是這將面臨一個問題就是使用IP承載會因為IP報文較長而導致傳輸速率的降低，這是運營商不可接受的，這種情況下可以採用CRTP技術將IP頭壓縮到2到4個位元組，這樣就達到了和ATM承載相當的速度。上圖中R1和R2、R3和R4之間就採用了這種技術。4結束語
壓縮RTP（CRTP）技術可以減小IP、UDP、RTP的包頭大小，極大的節省了頻寬，提高了傳輸效率。我司的接入系列路由器NE16/20在低速鏈路上已經支持了該項技術，並且可以達到線速轉發，對轉發性能和時延幾乎沒有什麼影響。在頻寬資源緊張的環境中可以使用我司路由器進行CRTP部署。
