本發(fā)明涉及一種低延遲的文本信息傳輸方法。

背景技術(shù)：

電信領(lǐng)域推出了基于IP包交換的融合通信業(yè)務(wù)規(guī)范RCS，基于RCS標(biāo)準(zhǔn)，不但能夠?qū)崿F(xiàn)類似于互聯(lián)網(wǎng)的IM通信應(yīng)用(如微信、WhatsApp、Line等)的豐富的消息功能，而且能做到在手機(jī)原生系統(tǒng)中，像發(fā)短信、打電話那樣進(jìn)行操作。而且，作為全球性的規(guī)范，RCS應(yīng)用能夠?qū)崿F(xiàn)各家運(yùn)營商之間互聯(lián)互通。事實(shí)上，類似的基于SIP/XML協(xié)議的應(yīng)用還有許多國際標(biāo)準(zhǔn)，如XMPP也可實(shí)現(xiàn)類似的功能。

RCS、XMPP等協(xié)議規(guī)范主要應(yīng)用于豐富媒體(文字、語音、圖片、視頻、文件)的即時(shí)消息的傳輸，協(xié)議是基于文本的，具有靈活、易懂、易擴(kuò)展的特點(diǎn)。

RCS、XMPP或類似基于文本的協(xié)議的缺點(diǎn)是，相比高度優(yōu)化的私有協(xié)議的應(yīng)用(如微信、WhatsApp、Line等)，其消息的延遲比較大。主要原因是，文本協(xié)議本身有較多冗余，加上報(bào)文頭，其協(xié)議報(bào)文的體積很大；加上網(wǎng)絡(luò)有丟包的情況時(shí)，網(wǎng)絡(luò)重傳會(huì)導(dǎo)致進(jìn)一步的延遲。盡管SigComp(信令壓縮協(xié)議)能夠解決報(bào)文體積大的問題，但由于其實(shí)現(xiàn)復(fù)雜(需要支持動(dòng)態(tài)加載虛擬機(jī)和壓縮字典)，首次載入壓縮效率低等問題，實(shí)際應(yīng)用較少。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明所要解決的技術(shù)問題是針對(duì)上述現(xiàn)有技術(shù)提供一種低延遲的文本信息傳輸方法。

本發(fā)明解決上述技術(shù)問題所采用的技術(shù)方案為：一種低延遲的文本信息傳輸方法，其特征在于：在互通文本信息的第一終端和第二終端之間建立如下握手機(jī)制：

擁有壓縮和解壓縮能力的第一終端能處理沒有壓縮和解壓縮能力的第二終端發(fā)來的文本信息；此時(shí)，第一終端和第二終端在進(jìn)行文本信息互通時(shí)，將要傳遞的文本信息，按照沒有壓縮過的標(biāo)準(zhǔn)格式報(bào)文進(jìn)行互通；

擁有壓縮和解壓縮能力的第一終端能處理擁有壓縮和解壓縮能力的第二終端發(fā)來的文本信息，其中第一終端和第二終端均擁有數(shù)據(jù)壓縮字典，且第一終端擁有的數(shù)據(jù)壓縮字典的版本號(hào)高于或等于第二終端均擁有數(shù)據(jù)壓縮字典的版本號(hào)，版本號(hào)高的數(shù)據(jù)壓縮字典的內(nèi)容包含有版本號(hào)低的數(shù)據(jù)壓縮字典內(nèi)容；此時(shí)第一終端和第二終端在進(jìn)行文本信息互通時(shí)，將要傳遞的文本信息，按照彼此之間版本號(hào)較低的數(shù)據(jù)壓縮字典進(jìn)行壓縮后傳輸，收到文本信息的終端按照版本號(hào)較低的數(shù)據(jù)壓縮字典進(jìn)行解壓縮得到要傳遞的文本信息。

作為改進(jìn)，將互通文本信息的第一終端和第二終端之間使用頻率大于設(shè)定閾值的字符或/和字符串，建立成一個(gè)基礎(chǔ)版本的數(shù)據(jù)壓縮字典，并將該基礎(chǔ)版本的數(shù)據(jù)壓縮字典均保存在第一終端和第二終端內(nèi)。

再改進(jìn)，在互通文本信息的第一終端和第二終端之間建立三種不同的信息互通類型：

第一類型：沒有服務(wù)器參與，且第一終端具有壓縮和解壓縮能力，第二終端不具有壓縮和解壓縮能力：第一終端發(fā)送的第一個(gè)文本信息為沒有壓縮過的標(biāo)準(zhǔn)格式報(bào)文，該標(biāo)準(zhǔn)格式報(bào)文內(nèi)攜帶有第一終端具備壓縮和解壓縮能力及其數(shù)據(jù)壓縮字典的版本號(hào)，第二終端忽略第一個(gè)文本信息中的壓縮能力字段后按照正常方式進(jìn)行后續(xù)處理；

第二類型：沒有服務(wù)器參與，且第一終端和第二終端均具有壓縮和解壓縮能力：第一終端發(fā)送的第一個(gè)文本信息為沒有壓縮過的標(biāo)準(zhǔn)格式報(bào)文，該標(biāo)準(zhǔn)格式報(bào)文內(nèi)攜帶有第一終端具備壓縮和解壓縮能力及其數(shù)據(jù)壓縮字典的版本號(hào)；第二終端收到第一終端發(fā)來的第一個(gè)文本信息后，提取第一終端的數(shù)據(jù)壓縮字典的版本號(hào)，然后與自身攜帶的數(shù)據(jù)壓縮字典的版本號(hào)進(jìn)行對(duì)比，然后將回復(fù)的文本信息按第一終端和第二終端中版本低的數(shù)據(jù)壓縮字典進(jìn)行壓縮，且對(duì)壓縮后的文本信息增加報(bào)文頭，報(bào)文頭中說明了壓縮算法和字典的版本號(hào)；第一終端收到回復(fù)的文本信息后根據(jù)報(bào)文頭的說明，通過對(duì)應(yīng)的解壓模塊使用低版本的數(shù)據(jù)壓縮字典完成解壓，同時(shí)在第一終端的通訊錄中緩存更新第二終端的設(shè)備信息，該設(shè)備信息包括設(shè)備ID、用戶ID及其數(shù)據(jù)壓縮字典的版本號(hào)；此后，第一終端和第二終端所有的文本信息互通都使用確定的數(shù)據(jù)壓縮字典版本進(jìn)行壓縮和解壓；

第三類型：有服務(wù)器參與，且第一終端和第二終端均具有壓縮和解壓縮能力：第一終端和第二終端首次連接服務(wù)器時(shí)，將其設(shè)備信息以及數(shù)據(jù)壓縮字典的版本號(hào)發(fā)送給服務(wù)器，服務(wù)器保存記錄；當(dāng)?shù)谝唤K端需要與第二終端進(jìn)行信息互通時(shí)，第一終端向服務(wù)器查詢第二終端的設(shè)備信息以及數(shù)據(jù)壓縮字典的版本號(hào)，服務(wù)器向第一終端返回第二終端設(shè)備信息以及數(shù)據(jù)壓縮字典的版本號(hào)，第一終端將獲取的第二終端設(shè)備信息以及數(shù)據(jù)壓縮字典的版本號(hào)保存到本地；第一終端與第二終端進(jìn)行信息互通時(shí)，用自身和對(duì)端都支持的最大數(shù)據(jù)壓縮字典的版本進(jìn)行壓縮或解壓縮處理。

再改進(jìn)，在所述第二類型中，如果第一終端和第二終端任何一方的數(shù)據(jù)壓縮字典升級(jí)，在發(fā)送的文本信息中增加更新后的數(shù)據(jù)壓縮字典的版本號(hào)的報(bào)文頭，第一終端或第二終端收到對(duì)方新的數(shù)據(jù)壓縮字典的版本號(hào)時(shí)，然后跟自己所支持的數(shù)據(jù)壓縮字典版本號(hào)比較，取兩者較低的版本進(jìn)行壓縮或解壓縮。

再改進(jìn)，第一終端和第二終端在進(jìn)行信息互通時(shí)，如果需要壓縮文本信息，則采用GZIP壓縮算法對(duì)文本信息進(jìn)行壓縮。

再改進(jìn)，所述第二類型中，如果第二終端重新安裝了數(shù)據(jù)壓縮字典，且更新后的數(shù)據(jù)壓縮字典的版本比之前已經(jīng)確定的第一終端和第二終端互通時(shí)使用的數(shù)據(jù)壓縮字典的版本要低；此時(shí)，第一終端發(fā)送文本信息給第二終端時(shí)，使用了之前已經(jīng)確定的第一終端和第二終端互通時(shí)使用的數(shù)據(jù)壓縮字典的進(jìn)行壓縮，由于第二終端無法進(jìn)行解壓處理，此時(shí)，第二終端立即向第一終端發(fā)送一個(gè)錯(cuò)誤響應(yīng)，或者直接忽略此文本信息；當(dāng)?shù)谝唤K端收到錯(cuò)誤響應(yīng)時(shí)，或等待第二終端的響應(yīng)超過預(yù)設(shè)時(shí)間閾值，預(yù)設(shè)時(shí)間閾值為1000ms～2000ms，第一終端重新發(fā)送沒有壓縮過的標(biāo)準(zhǔn)格式報(bào)文，然后第一終端和第二終端按照第二類型中描述的方式，重新確定第一終端和第二終端之間文本信息互通所使用的數(shù)據(jù)壓縮字典版本號(hào)。

再改進(jìn)，在所述第三類型中，當(dāng)有新版本的數(shù)據(jù)壓縮字典時(shí)，只需要在服務(wù)器端更新新版本的數(shù)據(jù)壓縮字典，然后當(dāng)?shù)谝唤K端和第二終端登錄服務(wù)器時(shí)，或在第一終端和第二終端空閑時(shí)，將新版本的數(shù)據(jù)壓縮字典發(fā)送給第一終端和第二終端。

再改進(jìn)，在第一終端和第二終端進(jìn)行信息互通時(shí)，通過前向糾錯(cuò)機(jī)制來發(fā)送文本信息，即通過增加冗余包的方式來增加信息互通成功率。

與現(xiàn)有技術(shù)相比，本發(fā)明的優(yōu)點(diǎn)在于：采用本發(fā)明提供的文本信息傳輸方法，能實(shí)現(xiàn)平均比優(yōu)化前提高一倍的傳輸速度，即減少一半延遲；在進(jìn)一步方案中，壓縮技術(shù)能使流量減少至原先的15％～20％。

附圖說明

圖1為本發(fā)明實(shí)施例中具有不同版本數(shù)據(jù)壓縮字典的第一終端和第二終端之間文本信息互通框圖；

圖2為本發(fā)明實(shí)施例中在無服務(wù)器參與情況下具有壓縮解壓縮能力的第一終端跟不帶壓縮能力的第二終端之間的文本信息互通框圖；

圖3為本發(fā)明實(shí)施例中在無服務(wù)器參與情況下具有壓縮解壓縮能力的第一終端跟同樣帶壓縮能力的第二終端之間的文本信息互通框圖；

圖4為本發(fā)明實(shí)施例中在有服務(wù)器參與情況下具有壓縮解壓縮能力的第一終端跟同樣帶壓縮能力的第二終端之間的文本信息互通框圖。

具體實(shí)施方式

以下結(jié)合附圖實(shí)施例對(duì)本發(fā)明作進(jìn)一步詳細(xì)描述。

本發(fā)明提供的低延遲的文本信息傳輸方法，其核心宗旨在于：在互通文本信息的第一終端和第二終端之間建立如下握手機(jī)制：

擁有壓縮和解壓縮能力的第一終端能處理沒有壓縮和解壓縮能力的第二終端發(fā)來的文本信息；此時(shí)，第一終端和第二終端在進(jìn)行文本信息互通時(shí)，將要傳遞的文本信息，按照沒有壓縮過的標(biāo)準(zhǔn)格式報(bào)文進(jìn)行互通；

擁有壓縮和解壓縮能力的第一終端能處理擁有壓縮和解壓縮能力的第二終端發(fā)來的文本信息，其中第一終端和第二終端均擁有數(shù)據(jù)壓縮字典，且第一終端擁有的數(shù)據(jù)壓縮字典的版本號(hào)高于或等于第二終端均擁有數(shù)據(jù)壓縮字典的版本號(hào)，版本號(hào)高的數(shù)據(jù)壓縮字典的內(nèi)容包含有版本號(hào)低的數(shù)據(jù)壓縮字典內(nèi)容；此時(shí)第一終端和第二終端在進(jìn)行文本信息互通時(shí)，將要傳遞的文本信息，按照彼此之間版本號(hào)較低的數(shù)據(jù)壓縮字典進(jìn)行壓縮后傳輸，收到文本信息的終端按照版本號(hào)較低的數(shù)據(jù)壓縮字典進(jìn)行解壓縮得到要傳遞的文本信息。

以GZIP(RFC 1952，GZIP file format specification version 4.3)或類似的壓縮算法為例，GZIP是基于LZ77和Huffman編碼，比較適合對(duì)文本數(shù)據(jù)進(jìn)行壓縮處理，因此通常也會(huì)應(yīng)用于壓縮HTTP報(bào)文(RFC 2616)，因此，本發(fā)明可以將它應(yīng)用于壓縮SIP/SDP/XML等類似的文本協(xié)議，當(dāng)然也可以采用其他壓縮算法；下文以SIP呼叫信令I(lǐng)NVITE為例展開描述，然而實(shí)際也適用于任何其它以文本協(xié)議為基礎(chǔ)的實(shí)時(shí)通信應(yīng)用，如發(fā)送IM消息或通知等等。

GZIP的壓縮率取決于被壓縮報(bào)文的大小，也取決于壓縮參考字典的相關(guān)性和大小，因此對(duì)于壓縮字典的動(dòng)態(tài)維護(hù)是比較重要的。

圖1描述了基于GZIP壓縮系統(tǒng)的數(shù)據(jù)壓縮字典可不斷增量而擴(kuò)展版本的概念，并且其為向下兼容的；意思即為，擁有高版本的數(shù)據(jù)壓縮字典的壓縮編解碼系統(tǒng)可以處理相同或較低版本的數(shù)據(jù)壓縮字典的壓縮數(shù)據(jù)。如圖1，第一終端使用的數(shù)據(jù)壓縮字典版本號(hào)為Dict v1.1，其可以跟第二終端使用的數(shù)據(jù)壓縮字典版本號(hào)為Dict v1.1互通，即實(shí)現(xiàn)壓縮、解壓的過程；第二終端還擁有更高版本的數(shù)據(jù)壓縮字典Dict v1.2，事實(shí)上第一終端和第二終端還可以跟任何支持?jǐn)?shù)據(jù)壓縮字典版本號(hào)為Dict v1.0或Dict v1.1的終端互通。

由于實(shí)際應(yīng)用中，我們往往事先知道有哪些字符或字符串是經(jīng)常使用的，比如SIP、SDP、INVITE、200OK等等，我們可以預(yù)設(shè)一個(gè)Dict v1.0作為基礎(chǔ)版本的數(shù)據(jù)壓縮字典，并將該基礎(chǔ)版本的數(shù)據(jù)壓縮字典均保存在第一終端和第二終端內(nèi)經(jīng)過實(shí)際測試，針對(duì)性的規(guī)定一個(gè)大概20Kbytes大小的數(shù)據(jù)字典，基于GZIP壓縮后，RCS/SIP/XMPP報(bào)文體積平均可減小到原來的15％～20％。

本發(fā)明還充分考慮了各個(gè)版本的互通性和平滑升級(jí)問題，在互通文本信息的第一終端和第二終端之間建立三種不同的信息互通類型：

第一類型：沒有服務(wù)器參與，且第一終端具有壓縮和解壓縮能力，第二終端不具有壓縮和解壓縮能力，如圖2：第一終端發(fā)送的第一個(gè)文本信息為沒有壓縮過的標(biāo)準(zhǔn)格式報(bào)文，該標(biāo)準(zhǔn)格式報(bào)文內(nèi)攜帶有第一終端具備壓縮和解壓縮能力及其數(shù)據(jù)壓縮字典的版本號(hào)，第二終端忽略第一個(gè)文本信息中的壓縮能力字段后按照正常方式進(jìn)行后續(xù)處理；

第二類型：沒有服務(wù)器參與，且第一終端和第二終端均具有壓縮和解壓縮能力，如圖3：第一終端發(fā)送的第一個(gè)文本信息為沒有壓縮過的標(biāo)準(zhǔn)格式報(bào)文，該標(biāo)準(zhǔn)格式報(bào)文內(nèi)攜帶有第一終端具備壓縮和解壓縮能力及其數(shù)據(jù)壓縮字典的版本號(hào)；第二終端收到第一終端發(fā)來的第一個(gè)文本信息后，提取第一終端的數(shù)據(jù)壓縮字典的版本號(hào)，然后與自身攜帶的數(shù)據(jù)壓縮字典的版本號(hào)進(jìn)行對(duì)比，然后將回復(fù)的文本信息按第一終端和第二終端中版本低的數(shù)據(jù)壓縮字典進(jìn)行壓縮，且對(duì)壓縮后的文本信息增加報(bào)文頭，報(bào)文頭中說明了壓縮算法和字典的版本號(hào)；第一終端收到回復(fù)的文本信息后根據(jù)報(bào)文頭的說明，通過對(duì)應(yīng)的解壓模塊使用低版本的數(shù)據(jù)壓縮字典完成解壓，同時(shí)在第一終端的通訊錄中緩存更新第二終端的設(shè)備信息，該設(shè)備信息包括設(shè)備ID、用戶ID及其數(shù)據(jù)壓縮字典的版本號(hào)；此后，第一終端和第二終端所有的文本信息互通都使用確定的數(shù)據(jù)壓縮字典版本進(jìn)行壓縮和解壓；

第二類型還可以考慮通信對(duì)端中版本數(shù)據(jù)壓縮字典回退到更早期的版本的異常情況，如果第二終端重新安裝了數(shù)據(jù)壓縮字典，且更新后的數(shù)據(jù)壓縮字典的版本比之前已經(jīng)確定的第一終端和第二終端互通時(shí)使用的數(shù)據(jù)壓縮字典的版本要低；此時(shí)，第一終端發(fā)送文本信息給第二終端時(shí)，使用了之前已經(jīng)確定的第一終端和第二終端互通時(shí)使用的數(shù)據(jù)壓縮字典的進(jìn)行壓縮，由于第二終端無法進(jìn)行解壓處理，此時(shí)，第二終端立即向第一終端發(fā)送一個(gè)錯(cuò)誤響應(yīng)，或者直接忽略此文本信息；當(dāng)?shù)谝唤K端收到錯(cuò)誤響應(yīng)時(shí)，或等待第二終端的響應(yīng)超過預(yù)設(shè)時(shí)間閾值，預(yù)設(shè)時(shí)間閾值為1000ms～2000ms，第一終端重新發(fā)送沒有壓縮過的標(biāo)準(zhǔn)格式報(bào)文，然后第一終端和第二終端按照第二類型中描述的方式，重新確定第一終端和第二終端之間文本信息互通所使用的數(shù)據(jù)壓縮字典版本號(hào)。如果由于網(wǎng)絡(luò)延遲或丟包等原因，第二終端的響應(yīng)沒有在超時(shí)之前發(fā)送給第一終端造成的誤判，由于第一終端和第二終端還是可以處理無壓縮的文本信息，因此邏輯上也能正常工作；之后，再次建立壓縮能力和字典版本號(hào)的確認(rèn)握手后，仍可按圖3的類似流程實(shí)現(xiàn)互通，并享受壓縮的好處。

因此，我們在原有通信終端上加入一層“信令壓縮模塊”，對(duì)于壓縮后的數(shù)據(jù)加上4個(gè)字節(jié)的頭部描述Comp Header：一個(gè)字節(jié)為壓縮算法類型、一個(gè)字節(jié)為字典版本號(hào)、另一個(gè)字節(jié)為交驗(yàn)字節(jié)、剩余一字節(jié)為保留8位，壓縮數(shù)據(jù)本身格式由GZIP或類似算法定義，本文不再描述，信令壓縮模塊接收文本信息后，子模塊Selector根據(jù)檢查頭部Comp Header來判斷是否需要解壓，以及解壓數(shù)據(jù)壓縮字典的版本號(hào)，來選擇直接透傳給上層，還是通過某版本數(shù)據(jù)壓縮字典進(jìn)行解壓處理后再將原始未壓縮數(shù)據(jù)傳給上層，反方向的，信令壓縮模塊接收上層原始文本信息，和對(duì)端版本類型指示“未知”、或“壓縮算法，字典版本號(hào)”來處理：如果是未知，則在原始的SIP文本信息中插入如“GZIP Comp,Dict v1.1”，根據(jù)本端的壓縮算法，字典版本號(hào)，發(fā)送未壓縮報(bào)文；如果是已知對(duì)端“壓縮算法，字典版本號(hào)”，則跟本端“壓縮算法，字典版本號(hào)”進(jìn)行匹配，取兩者較低版本的字典進(jìn)行壓縮后發(fā)送壓縮報(bào)文；

第三類型：有服務(wù)器參與，且第一終端和第二終端均具有壓縮和解壓縮能力，如圖4所示：第一終端和第二終端首次連接服務(wù)器時(shí)，將其設(shè)備信息以及數(shù)據(jù)壓縮字典的版本號(hào)發(fā)送給服務(wù)器，服務(wù)器保存記錄；當(dāng)?shù)谝唤K端需要與第二終端進(jìn)行信息互通時(shí)，第一終端向服務(wù)器查詢第二終端的設(shè)備信息以及數(shù)據(jù)壓縮字典的版本號(hào)，服務(wù)器向第一終端返回第二終端設(shè)備信息以及數(shù)據(jù)壓縮字典的版本號(hào)，第一終端將獲取的第二終端設(shè)備信息以及數(shù)據(jù)壓縮字典的版本號(hào)保存到本地；第一終端與第二終端進(jìn)行信息互通時(shí)，用自身和對(duì)端都支持的最大數(shù)據(jù)壓縮字典的版本進(jìn)行壓縮或解壓縮處理；

在所述第三類型中，當(dāng)有新版本的數(shù)據(jù)壓縮字典時(shí)，只需要在服務(wù)器端更新新版本的數(shù)據(jù)壓縮字典，然后當(dāng)?shù)谝唤K端和第二終端登錄服務(wù)器時(shí)，或在第一終端和第二終端空閑時(shí)，將新版本的數(shù)據(jù)壓縮字典發(fā)送給第一終端和第二終端。

在第三類型場景下，如果碰到終端回退到不支持信令壓縮的老版本時(shí)，終端登錄到服務(wù)器時(shí)不會(huì)帶上支持信令壓縮及字典版本號(hào)的信息，服務(wù)器就保存此終端屬性，當(dāng)另一個(gè)終端以壓縮信令呼叫此終端，且還未來得及進(jìn)行能力查詢時(shí)，服務(wù)器返回錯(cuò)誤碼，則呼叫端重新以同一會(huì)話ID發(fā)送未壓縮的信令進(jìn)行后續(xù)的交互。服務(wù)器處理第二終端換回不支持壓縮功能版本的異常，如果第一終端在呼叫前對(duì)此回退到不支持信令壓縮的老版本的終端進(jìn)行能力查詢，則可提前更新此好友屬性，直接采用不壓縮的方式進(jìn)行交互。

隨著電信和互聯(lián)網(wǎng)的基礎(chǔ)設(shè)施的快速發(fā)展，網(wǎng)絡(luò)的帶寬越來越大，信令相對(duì)于以幾兆到幾百兆級(jí)別的網(wǎng)絡(luò)鏈路而言，實(shí)際上只占用非常小比例的帶寬。一般的一個(gè)SIP呼叫信令報(bào)文大概只有3～4Kbytes，如果希望500ms送達(dá)，理論所需要占用帶寬為4*8*1000/500＝64kbps；如果使用GZIP進(jìn)行壓縮后，大概只有0.5Kbytes，理論所需要占帶寬8kbps。如果是5Mbps網(wǎng)絡(luò)可用帶寬，那么4Kbytes報(bào)文的按理論傳輸最快速率計(jì)算，只需要4*8*1000/(5*1024)＝6.25ms就能傳輸完成，壓縮后的報(bào)文大小約為0.5Kbytes，最快只需要不到1ms就能傳輸完成。然而實(shí)際考慮到網(wǎng)絡(luò)的固有延遲，包括交換機(jī)路由器的處理延遲，電信號(hào)傳輸延遲(光速)，實(shí)際的延遲會(huì)有幾十毫秒到幾百毫秒。有一點(diǎn)可以確定的是，如果不考慮丟包，在5M帶寬及以上級(jí)別的網(wǎng)絡(luò)環(huán)境下傳輸4K字節(jié)跟0.5K字節(jié)或者10K字節(jié)，從網(wǎng)絡(luò)層(IP層)的角度來看，總的延遲差距不大，應(yīng)該在20ms以內(nèi)。但在傳輸層和應(yīng)用層角度看，信令是需要可靠傳輸?shù)?，不得不考慮丟包問題，通常我們通過握手(ACK或NACK)重傳實(shí)現(xiàn)可靠性，因此每個(gè)丟包都會(huì)引起增加至少一個(gè)RTT(往返延遲時(shí)間)或500毫秒(未收到ACK自動(dòng)重發(fā))的額外延遲?？紤]到一般MTU為1500字節(jié)，4K字節(jié)需要拆分為3個(gè)包發(fā)送，設(shè)當(dāng)前丟包率10％(我們監(jiān)測到的全球互聯(lián)網(wǎng)的平均丟包率)，那么3個(gè)包一次完整到達(dá)的概率為pow((1-10％),3)＝72.9％，也就是說，在不能完整到達(dá)的情況下，延遲至少會(huì)增加一個(gè)RTT，還有較大概率會(huì)增加2～3個(gè)RTT的延遲，根據(jù)我們監(jiān)測數(shù)據(jù)全球互聯(lián)網(wǎng)視頻通話的平均RTT達(dá)500ms。如果，報(bào)文只有0.5K字節(jié)，即只需要一個(gè)打包，那么完整到達(dá)的概率就是90％。從應(yīng)用層來看，一個(gè)信令發(fā)送最簡單的過程是“終端--服務(wù)端--終端”，即一個(gè)來回有4次傳輸，如果信令報(bào)文大小是4K，設(shè)丟包率10％，則一次最簡單的業(yè)務(wù)流程不重傳的概率為pow((1-10％),12)＝28.24％；而信令壓縮后的不重傳概率為pow((1-10％),4)＝65.61％。因此由于丟包現(xiàn)象的存在，基于4K字節(jié)的信令的應(yīng)用層看到的延遲會(huì)遠(yuǎn)遠(yuǎn)高于壓縮后0.5K字節(jié)的情況。

如果我們通過采用reed-solomon(Reed,Irving S.；Solomon,Gustave(1960),"Polynomial Codes over Certain Finite Fields",Journal of the Society for Industrial and Applied Mathematics(SIAM)8(2):300–304,doi:10.1137/0108018)的算法實(shí)現(xiàn)FEC，即發(fā)送n個(gè)包，其中的k個(gè)包為原始需要發(fā)送的包，n-k為冗余包個(gè)數(shù)，則在n個(gè)包中任意傳輸成功k個(gè)及以上的包，都能恢復(fù)出所有原始發(fā)送數(shù)據(jù)，這里n為6，k為4，冗余2個(gè)包，傳輸過程中丟任意2個(gè)包都能夠恢復(fù)。按照這種算法，設(shè)PAR(Packet arrival rate)為包到達(dá)率(PAR＝1-丟包率)，設(shè)PFA(probability of an integral frame arrival)為完整數(shù)據(jù)幀(所有原始數(shù)據(jù))的到達(dá)概率，則有如下計(jì)算公式：

按照上面的例子，對(duì)于未壓縮的報(bào)文，增加2個(gè)FEC冗余包，則n＝5,k＝3,PAR＝90％；則一個(gè)通路的信令完整到達(dá)概率為99.14％；4個(gè)通路即一個(gè)應(yīng)用層會(huì)話一次性完成的概率為pow(99.144％,4)＝96.6％。對(duì)于壓縮后的報(bào)文，增加一個(gè)冗余包，則一個(gè)通路信令完整到達(dá)的概率為99％；4個(gè)通路即一個(gè)應(yīng)用層會(huì)話一次性完成的概率為pow(99％,4)＝96.1％。如前所述，在以兆帶寬為單位的環(huán)境下，增加幾個(gè)包的FEC冗余增加的流量比較有限，且并不會(huì)增加延遲；由于一次成功完成應(yīng)用層會(huì)話的業(yè)務(wù)的概率大大提升，而無須重傳引入多個(gè)RTT的延遲。

通過上述信令壓縮和前向糾錯(cuò)的方法，可降低碼率、提高會(huì)話一次成功率，從而實(shí)現(xiàn)低延遲的可靠數(shù)據(jù)的傳輸，尤其適用于SIP/RCS協(xié)議中會(huì)話建立過程，提高用戶體驗(yàn)。建議對(duì)呼叫敏感的業(yè)務(wù)默認(rèn)增加1～2個(gè)冗余，對(duì)于發(fā)送IM等業(yè)務(wù)，考慮到減少冗余，兼顧發(fā)送實(shí)時(shí)性，可根據(jù)會(huì)話過程中統(tǒng)計(jì)的丟包率，來動(dòng)態(tài)設(shè)定冗余比例。