多個壓縮包到達，解壓器應該為每個收到的壓縮包重新傳輸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位會話環境:
             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           | 1 = IP/UDP/RTP 如CID為8位	   |
           +---+---+---+---+---+---+---+---+
           |         	會話計數           |
           +---+---+---+---+---+---+---+---+
           +---+---+---+---+---+---+---+---+
           |       		會話環境ID  	   |
           +---+---+---+---+---+---+---+---+
           | I | 0 | 0 | 0 |    順序號	   |
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+
                          ...
           +---+---+---+---+---+---+---+---+
           |       		會話環境 ID        |
           +---+---+---+---+---+---+---+---+
           | I | 0 | 0 | 0 |    順序號	   |
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+
   	2表示使用16位的會話環境ID。
會話環境ID按照網絡字節順序發送（最高位優先）：
             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           | 2 = IP/UDP/RTP 如CID為16位	   |
           +---+---+---+---+---+---+---+---+
           |         會話數目	           |
           +---+---+---+---+---+---+---+---+
           +---+---+---+---+---+---+---+---+
           |                               |
           +       會話環境ID              +
           |                               |
           +---+---+---+---+---+---+---+---+
           | I | 0 | 0 | 0 |    順序號     |
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+
                          ...
           +---+---+---+---+---+---+---+---+
           |                               |
           +       會話環境ID              +
           |                               |
           +---+---+---+---+---+---+---+---+
           | I | 0 | 0 | 0 |    順序號     |
           +---+---+---+---+---+---+---+---+
           | 0 | 0 |       generation      |
           +---+---+---+---+---+---+---+---+
   在標志為無效，要發送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和RR RTCP包中的數字內容不好壓縮，但SDES包中的文本信息可以壓
縮到一個屏蔽位表示每個存在并已壓縮的項(用于對SDES NOTE項進行計時并允許端系統為
計算間隔而測量平均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.非RTP UDP包壓縮
   如前所述，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頭壓縮的討論。Carsten Bormann開發了低速鏈
路上帶傳輸控制的壓縮體系結構，同時對于本文描述的方案也作出了一些特別貢獻。David 
Oran獨立開發了一個基于本文類似思想的Note，并建議使用PPP多鏈路協議進行分片。Mikael 
Degermark在把本方案同IPv6壓縮框架進行集成方面作出了貢獻。
7.參考文獻
   [1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
       A Transport Protocol for real-time applications", RFC 1889,
       January 1996.
   [2] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links",
       RFC 1144, February 1990.
   [3] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for
       IPv6", RFC 2507, February 1999.
   [4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
       1661, July 1994.
   [5] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP
       Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
8.安全性考慮
   由于加密會消除本壓縮方案所試圖實現的冗余性，所以為了在低帶寬鏈路上完成操作我們考
慮可能要放棄加密。不過對于那些需要壓縮數據而不是包頭的情況，RTP已經規定了另一種可選
的加密方法，它只壓縮RTP負載而將包頭保持明文。這樣壓縮依然可以使用。
   一個有問題的或是惡意的壓縮器可能使解壓器重組的包同原始包不一致卻有有效的IP, IDP，
RTP頭，甚至有效的UDP校驗和。這樣的破壞可通過端到端認證和完整性機制（它不會受到壓縮的
影響）檢測出來。認證頭中的恒定部分可通過[3]所描述的方法進行壓縮。
   本協議在發送CONTEXT_STATE控制包時沒有執行任何認證。有權訪問壓縮器和解壓器之間鏈路
的攻擊者可以通過插入錯誤的包使壓縮效率下降，甚至導致鏈路擁塞。不過他們還可以通過許多
其他方式來破壞通信。如果使用的壓縮技術會造成接收端計算負荷不均衡，系統就有潛在拒絕服
務式攻擊的威脅。攻擊者可通過插入病態報文造成解壓縮復雜性增加，導致接收端過載和處理其
它流的效率降低。然而，本壓縮方案并未顯示出有任何明顯的波動性。
對本協議的安全性回顧并沒有發現任何多余的安全性考慮。
9.作者地址
   Stephen L. Casner
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   United States
   EMail: casner@cisco.com
   Van Jacobson
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   United States
   EMail: van@cisco.com
10.版權聲明
   Copyright (C) The Internet Society (1999).  All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.
   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
RFC2508  Compressing IP/UDP/RTP Headers for Low-Speed Serial Links     低速串行鏈
路下IP/UDP/RTP數據包頭的壓縮


1
RFC文檔中文翻譯計劃