日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁 > 云知道 > >

低速串行鏈路下IP/UDP/RTP數(shù)據(jù)包頭的壓縮( 九 )

云知道


I000順序號(hào)
--- --- --- --- --- --- --- ---
00generation
--- --- --- --- --- --- --- ---
在標(biāo)志為無效，要發(fā)送COMPRESSED_NON_TCP包或FULL_HEADER的環(huán)境中，"I"位應(yīng)設(shè)置為1 。
假如I為0，則環(huán)境處于咨詢狀態(tài) 。I位設(shè)為0表示、在鏈路錯(cuò)誤指示后要發(fā)送環(huán)境咨詢狀態(tài) 。
由于CONTEXT_STATE包本身也可能丟失，所以答應(yīng)對(duì)一個(gè)或多個(gè)塊重傳輸 。但希望只有在接
收到另一個(gè)包時(shí)才觸發(fā)重傳輸，假如鏈路幾乎空閑時(shí)，可用一個(gè)相對(duì)較長的計(jì)時(shí)器來觸發(fā)重
傳輸(如定為1秒) 。假如給定環(huán)境的塊被重傳輸，它可能與用來刷新環(huán)境的FULL_HEADER或
COMPRESSED_NON_TCP錯(cuò)過 。這時(shí)壓縮器可以忽略錯(cuò)誤指示 。
在需要傳輸U(kuò)DP校驗(yàn)和的情況下，解壓器可以嘗試使用[3]的10.1節(jié)描述的"twice"算法 。
在該算法中，假設(shè)delta值與丟失包和隨后接收的一個(gè)包相同則delta要多次應(yīng)用 。校驗(yàn)和匹
配表示成功 。對(duì)于這里定義的方案，順序號(hào)的區(qū)別說明了delta必須要應(yīng)用的次數(shù) 。注重，
一個(gè)不正確的正指示可能會(huì)帶來一些小風(fēng)險(xiǎn) 。即便這里"twice"算法應(yīng)用成功，也建議發(fā)送
一個(gè)FULL_HEADER或COMPRESSED_NON_TCP包 。
有些錯(cuò)誤可能無法檢測出來，比如一排丟失了16個(gè)包且鏈路層沒有提供錯(cuò)誤指示 。在這
種情況下解壓器將產(chǎn)生無效的包 。假如UDP校驗(yàn)和正在傳輸，接收方可能會(huì)檢測到無效包并
且丟棄他們，但是接收方無法通知解壓器 。因此，建議解壓器周期性地驗(yàn)證UDP校驗(yàn)和，如
每16個(gè)包驗(yàn)證一次 。假如發(fā)現(xiàn)錯(cuò)誤，它應(yīng)將環(huán)境置為無效并且用一個(gè)CONTEXT_STATE包來通
知壓縮器 。
3.4.RTCP控制包壓縮
按照RTP協(xié)議規(guī)定，數(shù)據(jù)通過偶數(shù)端口發(fā)送，而RTCP包通過下一個(gè)奇數(shù)號(hào)端口進(jìn)行發(fā)送，
因此可以為RTP和RTCP包分別制定壓縮方案 。對(duì)于RTCP，壓縮同時(shí)針對(duì)包頭和數(shù)據(jù)本身，即
不同包類型的內(nèi)容 。SR和RRRTCP包中的數(shù)字內(nèi)容不好壓縮，但SDES包中的文本信息可以壓
縮到一個(gè)屏蔽位表示每個(gè)存在并已壓縮的項(xiàng)(用于對(duì)SDESNOTE項(xiàng)進(jìn)行計(jì)時(shí)并答應(yīng)端系統(tǒng)為
計(jì)算間隔而測量平均RTCP包大小) 。
然而由于一些原因（盡管壓縮應(yīng)該應(yīng)用于IP和UDP頭），在本壓縮方案中并不對(duì)RTCP頭和
數(shù)據(jù)進(jìn)行壓縮 。RTP協(xié)議規(guī)范建議應(yīng)該按比例決定RTCP包間隙，以便所有會(huì)話中參與者占用
的RTCP總帶寬不超過5%的會(huì)話總帶寬，所以壓縮RTCP并沒有太多的好處 。壓縮SDES項(xiàng)會(huì)造成
每個(gè)環(huán)境ID要存儲(chǔ)的共享狀態(tài)明顯增加 。并且，當(dāng)通過一個(gè)RTP混合器發(fā)送多個(gè)源的SDES信
息時(shí)，為了答應(yīng)壓縮就必須為每個(gè)SSRC標(biāo)識(shí)符維護(hù)一個(gè)單獨(dú)的RTCP會(huì)話環(huán)境 。在一個(gè)超過255
個(gè)參與者的會(huì)話中，即使只有一個(gè)參與者發(fā)送數(shù)據(jù)也會(huì)造成環(huán)境緩存中大量的垃圾數(shù)據(jù) 。假
設(shè)RTCP包作為COMPRESSED_UDP形式發(fā)送，即使不對(duì)其進(jìn)行壓縮，多數(shù)情況下它所占?jí)嚎s鏈路
的比重也不超過5% 。鑒于非壓縮RTCP包消耗的帶寬不超過會(huì)話總帶寬的5%，對(duì)于一個(gè)長度為
90字節(jié)的典型RTCP包，只要RTP數(shù)據(jù)包負(fù)載長度至少為108字節(jié)，則RTCP所占用的壓縮帶寬比
率也會(huì)不超過5% 。假如RTP負(fù)載長度比較小，該比率會(huì)有所提高，但對(duì)于負(fù)載大小為37字節(jié)
的RTP包而言，該比例仍不會(huì)超過7% 。假如RTP負(fù)載數(shù)據(jù)包很大，則壓縮RTCP所占的比例小于
非壓縮RTCP（如對(duì)1000字節(jié)的包該比例為4%） 。
3.5.非RTPUDP包壓縮
如前所述，COMPRESSED_UDP包可用來壓縮未攜帶RTP信息的UDP包 。UDP之頭后的任何數(shù)據(jù)
都不太可能象在RTP頭中相應(yīng)字段一樣有恒定不變的值 。非凡地，SSRC字段就很可能發(fā)生改

推薦閱讀