基本介紹
CRTP技術白皮書
1 前言
2 技術簡介
2.1 技術原理
2.2 壓縮字段
2.3 壓縮協議
2.4 RTCP控制包處理
3 應用舉例
4 結束語
5 參考資料
附錄A 縮略語
CRTP技術白皮書
關鍵詞： RTP、壓縮、CRTP
1 前言
語音數據包封裝成IP格式後，其實也就添加了針對UDP、IP和RTP（實時傳輸協議）的三個報頭。通常，一個語音數據包會包括20個字節的語音載荷流量和40個字節的這三個報頭，這樣就不利于充分發揮網絡的利用效率。所幸，40個字節的報頭信息可以利用壓縮RTP（CRTP）“壓縮”成2～4個字節。因為對每個信息流而言，這些報頭裡面的變化其實非常小。這顯然提高了數據傳輸效率，并且可以把G.729a呼叫（8K語音）所需的帶寬從24Kbps減小到12K～14Kbps左右。
2 技術簡介
IP包頭過長是影響其在無線網絡中應用的一個重要問題，解決這一問題的方案是采用頭部壓縮技術CRTP（RFC2508，低速串行鍊路下IP/UDP/RTP數據包頭的壓縮）。
CRTP的主要設計目标是在不發送UDP校驗和的情況下，将大多數包的IP/UDP/RTP頭壓縮到2個字節，在帶校驗和時則壓縮到4個字節。這一方案的提出主要是受使用14.4kb/s和28.8kb/s撥号調制解調器發送音視頻時遇到的相關問題所引起。這些鍊路提供全雙工通信，所以協議利用了這點，盡管協議在用于單工鍊路時可能性能會有所下降。該方案在本地鍊路上往返時間(RTT)很低，從而實現性能最高。
2.1 技術原理
頭部壓縮技術的原理是：語音編碼器生成的語音數據被逐層封裝成RTP，UDP和IP包。這樣的語音幀頭部長度達到40個字節，但是有效載荷隻有15～30個字節。這樣對于一個相的語音流來說，在連續的語音包中就有較高的冗餘度。要降低這種冗餘，必須使用壓縮算法。CRTP可以将40字節的包頭最小壓縮至2字節。用CRTP進行頭部壓縮，必須維護上下文信息（Context，即未壓縮的在通路兩端上一次發送的包頭），這樣，頭部僅僅攜帶上下文信息的變化即可。但是如果發生丢包或包被損壞，接收端就無法正确地更新上下文信息。所以必須提供相應的機制去監測上下文錯誤并去修複它。CRTP可以發送上下文更新請求來修複上下文，但是鍊路上的往返時間會影響這種修複機制的效率。圖1就是這種壓縮标準的一個示意圖。
圖1 CRTP壓縮示意圖
一般來說，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包。
2.2 壓縮字段
在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列表将在會話峰期間保持不變，所以它隻需在發生變化時才發送。
2.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 UDP包的非差分編碼當前産生号。對于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.4 RTCP控制包處理
呼叫建立一般使用實時信道建立控制協議（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部署。
