本發(fā)明涉及通信領(lǐng)域，具體而言，涉及一種報文處理方法及裝置。

背景技術(shù)：

在海上與陸地上的大部分區(qū)域是蜂窩式移動通訊系統(tǒng)的信號所不能覆蓋，因此，作為一種有效的補充手段，衛(wèi)星通訊被廣泛地應(yīng)用在上述的海上區(qū)域以及陸地上的大部分區(qū)域中，尤其是應(yīng)用于遠(yuǎn)洋運輸、鉆探、勘測以及漁業(yè)等部門。衛(wèi)星通信具有不受時間、地點、環(huán)境等多種因素的限制，開通時間短、傳輸距離遠(yuǎn)、網(wǎng)絡(luò)部署快、通信成本與通信距離無關(guān)等諸多優(yōu)點，可以實語音和數(shù)據(jù)的實時雙向傳輸。

其中，衛(wèi)星電話是現(xiàn)有實現(xiàn)衛(wèi)星通信的一種，由于衛(wèi)星信道具有與地面信道不同的一些特點，而傳輸控制協(xié)議(Transfer Control Protocol，簡稱為TCP)/互聯(lián)網(wǎng)協(xié)議(Internet Protocol，簡稱為IP)協(xié)議當(dāng)初是為地面網(wǎng)絡(luò)設(shè)計的，所以TCP/IP協(xié)議在衛(wèi)星信道上的傳輸性能比較差。存在以下問題：

1)一方面延遲大，衛(wèi)星信道的延時很長，典型的衛(wèi)星通信延時在540ms左右，這會造成TCP協(xié)議的不停的重傳，引起通信鏈路的擁塞。另一方面實際的衛(wèi)星通信中有很高的誤碼，而TCP協(xié)議不能區(qū)分出是網(wǎng)絡(luò)阻塞造成的數(shù)據(jù)丟失或是誤碼造成的數(shù)據(jù)丟失，TCP協(xié)議會一律認(rèn)為是網(wǎng)絡(luò)阻塞造成的，從而降低TCP的發(fā)送窗口，引起傳輸?shù)膸捪陆担?/p>

2)衛(wèi)星通信帶寬低且租用費用昂貴，基于網(wǎng)絡(luò)協(xié)議的語音傳輸(Voice over Internet Protocol，簡稱為VOIP)采用不同的編碼格式時，需要不同的數(shù)據(jù)帶寬，比如采用G729需要帶寬8Kbps，而一個報文頭(實時傳輸協(xié)議(Real-time Transport Protocol，簡稱為RTP)+用戶數(shù)據(jù)協(xié)議(User Date Protocol，簡稱為UDP)+IP頭)就占了16K bps，所以一路VOIP電話就需要占用24Kbps的帶寬，這對于衛(wèi)星通信來說是資源極大的浪費。

因此，在相關(guān)技術(shù)中，存在著語音通信在衛(wèi)星通訊領(lǐng)域上的帶寬利用率不足的問題，而針對該問題，目前尚未提出有效的解決方案。

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

本發(fā)明提供了一種報文處理方法及裝置，以至少解決相關(guān)技術(shù)中存在的語音通信在衛(wèi)星通訊領(lǐng)域上的帶寬利用率不足的問題。

根據(jù)本發(fā)明的一個方面，提供了一種報文處理方法，包括：按照與接收端協(xié)商的壓縮方式對待發(fā)送給所述接收端的實時傳輸協(xié)議RTP報文進(jìn)行壓縮；在壓縮成功后，通過衛(wèi)星將壓縮后的RTP報文發(fā)送給所述接收端。

可選地，通過如下方式與所述接收端協(xié)商所述壓縮方式：根據(jù)待發(fā)送給所述接收端的RTP報文的相關(guān)信息建立壓縮表，其中，所述壓縮表中攜帶當(dāng)前選擇的壓縮方式的標(biāo)識和所述RTP報文的相關(guān)信息，當(dāng)所述當(dāng)前選擇的壓縮方式為可靠頭壓縮ROCH或配置壓縮實時協(xié)議CRTP時，所述相關(guān)信息包括所述RTP報文的源互聯(lián)網(wǎng)協(xié)議IP地址、目的IP地址、用戶數(shù)據(jù)協(xié)議UDP源端口、UDP目的端口和RTP頭；或者，當(dāng)所述壓縮方式為配置壓縮用戶數(shù)據(jù)協(xié)議CUDP時，所述相關(guān)信息包括所述RTP報文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；將建立的所述壓縮表發(fā)送給所述接收端，其中，所述壓縮表用于指示所述接收端建立與所述壓縮表對應(yīng)的解壓縮表。

可選地，所述RTP報文的相關(guān)信息通過如下方式獲取：判斷接收到的待發(fā)送給所述接收端的報文是否是RTP報文；在判斷結(jié)果為所述報文是RTP報文的情況下，提取所述報文的相關(guān)信息作為所述RTP報文的相關(guān)信息。

可選地，判斷接收到的待發(fā)送給所述接收端的所述報文是否是RTP報文包括：判斷待發(fā)送給所述接收端的所述報文是否是UDP報文；當(dāng)確定所述報文是UDP報文后，判斷所述報文的UDP數(shù)據(jù)幀的字節(jié)數(shù)是否大于預(yù)定數(shù)量，如果大于所述預(yù)定數(shù)量，則判斷所述報文的UDP載荷中的預(yù)定位是否為預(yù)定值；當(dāng)確定所述報文的UDP載荷中的預(yù)定位是預(yù)定值時，判斷所述報文的有效載荷PAYLOAD的編碼格式是否為RTP的編碼格式；當(dāng)確定所述報文的PAYLOAD為RTP的編碼格式時，確定所述報文是RTP報文。

可選地，在將建立的所述壓縮表發(fā)送給所述接收端之后，所述方法還包括：接收攜帶掛斷指令的第一實時傳輸控制協(xié)議RTCP報文；向所述接收端發(fā)送第一通知消息，其中，所述第一通知消息用于通知所述接收端刪除所述解壓縮表；在接收到來自所述接收端的成功刪除響應(yīng)后，刪除所述壓縮表。

可選地，在按照預(yù)先與接收端協(xié)商的壓縮方式對待發(fā)送給所述接收端的所述RTP報文進(jìn)行壓縮之后，所述方法還包括：在壓縮RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)壓縮RTP報文失敗的時間超過第二閾值時，刪除所述壓縮表；向所述接收端發(fā)送第二通知消息，其中，所述第二通知消息用于通知所述接收端刪除所述解壓縮表。

可選地，在通過衛(wèi)星將壓縮后的RTP報文傳輸給所述接收端之后，所述方法還包括：接收來自所述接收端的用于通知刪除所述壓縮表的第三通知消息；根據(jù)所述第三通知消息刪除所述壓縮表。

可選地，所述第三通知消息包括以下至少之一：所述接收端在解壓縮壓縮后的RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)解壓縮壓縮后的RTP報文失敗的時間超過第二 閾值的情況下發(fā)送的通知消息；所述接收端在接收到攜帶掛斷指令的第二實時傳輸控制協(xié)議RTCP報文后發(fā)送的通知消息。

根據(jù)本發(fā)明的另一方面，提供了一種報文處理方法，包括：接收發(fā)送端通過衛(wèi)星發(fā)送的壓縮后的實時傳輸協(xié)議RTP報文；根據(jù)與所述發(fā)送端協(xié)商的解壓縮方式解壓縮所述壓縮后的RTP報文。

可選地，通過如下方式與所述發(fā)送端協(xié)商所述解壓縮方式：接收來自所述發(fā)送端的壓縮表；根據(jù)所述壓縮表建立用于解壓縮所述壓縮后的RTP報文的解壓縮表。

可選地，在根據(jù)所述壓縮表建立用于解壓縮所述壓縮后的RTP報文的所述解壓縮表之后，所述方法還包括：接收來自所述發(fā)送端的第四通知消息；根據(jù)所述第四通知消息刪除所述解壓縮表。

可選地，所述第四通知消息包括以下至少之一：所述發(fā)送端在壓縮待發(fā)送過來的RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)壓縮待發(fā)送過來的RTP報文失敗的時間超過第二閾值的情況下發(fā)送的通知消息；所述發(fā)送端在接收到攜帶掛斷指令的第一實時傳輸控制協(xié)議RTCP報文后發(fā)送的通知消息。

可選地，當(dāng)所述第四通知消息包括所述發(fā)送端在接收到攜帶掛斷指令的所述第一RTCP報文后發(fā)送的通知消息時，在根據(jù)所述第四通知消息刪除所述解壓縮表之后，所述方法還包括：向所述發(fā)送端發(fā)送成功刪除響應(yīng)，其中，所述成功刪除響應(yīng)用于指示所述發(fā)送端刪除所述壓縮表。

可選地，在接收來自所述發(fā)送端的所述壓縮表之后，所述方法還包括：接收攜帶掛斷指令的第二實時傳輸控制協(xié)議RTCP報文；向所述發(fā)送端發(fā)送第五通知消息，其中，所述第五通知消息用于通知所述發(fā)送端刪除所述壓縮表；在接收到來自所述發(fā)送端的成功刪除響應(yīng)后，刪除所述解壓縮表。

可選地，在根據(jù)與所述發(fā)送端協(xié)商的所述解壓縮方式解壓縮所述壓縮后的RTP報文之后，所述方法還包括：當(dāng)解壓縮壓縮后的RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)解壓縮壓縮后的RTP報文失敗的時間超過第二閾值后，刪除所述解壓縮表，并向所述發(fā)送端發(fā)送第六通知消息，其中，所述第六通知消息用于通知所述發(fā)送端刪除所述壓縮表。

根據(jù)本發(fā)明的另一方面，提供了一種報文處理裝置，包括：壓縮模塊，用于按照與接收端協(xié)商的壓縮方式對待發(fā)送給所述接收端的實時傳輸協(xié)議RTP報文進(jìn)行壓縮；第一發(fā)送模塊，用于在壓縮成功后，通過衛(wèi)星將壓縮后的RTP報文發(fā)送給所述接收端。

可選地，所述裝置還包括第一協(xié)商模塊，用于通過如下方式與所述接收端協(xié)商所述壓縮方式：根據(jù)待發(fā)送給所述接收端的RTP報文的相關(guān)信息建立壓縮表，其中，所述壓縮表中攜帶當(dāng)前選擇的壓縮方式的標(biāo)識和所述RTP報文的相關(guān)信息，當(dāng)所述當(dāng)前選 擇的壓縮方式為可靠頭壓縮ROCH或配置壓縮實時協(xié)議CRTP時，所述相關(guān)信息包括所述RTP報文的源互聯(lián)網(wǎng)協(xié)議IP地址、目的IP地址、用戶數(shù)據(jù)協(xié)議UDP源端口、UDP目的端口和RTP頭；或者，當(dāng)所述壓縮方式為配置壓縮用戶數(shù)據(jù)協(xié)議CUDP時，所述相關(guān)信息包括所述RTP報文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；將建立的所述壓縮表發(fā)送給所述接收端，其中，所述壓縮表用于指示所述接收端建立與所述壓縮表對應(yīng)的解壓縮表。

可選地，在獲取所述RTP報文的相關(guān)信息時，所述第一協(xié)商模塊包括：判斷單元，用于判斷接收到的待發(fā)送給所述接收端的報文是否是RTP報文；提取單元，用于在判斷結(jié)果為所述報文是RTP報文的情況下，提取所述報文的相關(guān)信息作為所述RTP報文的相關(guān)信息。

可選地，所述判斷單元通過如下方式判斷接收到的待發(fā)送給所述接收端的報文是否是RTP報文：判斷待發(fā)送給所述接收端的所述報文是否是UDP報文；當(dāng)確定所述報文是UDP報文后，判斷所述報文的UDP數(shù)據(jù)幀的字節(jié)數(shù)是否大于預(yù)定數(shù)量，如果大于所述預(yù)定數(shù)量，則判斷所述報文的UDP載荷中的預(yù)定位是否為預(yù)定值；當(dāng)確定所述報文的UDP載荷中的預(yù)定位是預(yù)定值時，判斷所述報文的有效載荷PAYLOAD的編碼格式是否為RTP的編碼格式；當(dāng)確定所述報文的PAYLOAD為RTP的編碼格式時，確定所述報文是RTP報文。

可選地，所述裝置還包括：第一接收模塊，用于在將建立的所述壓縮表發(fā)送給所述接收端之后，接收攜帶掛斷指令的第一實時傳輸控制協(xié)議RTCP報文；第二發(fā)送模塊，用于向所述接收端發(fā)送第一通知消息，其中，所述第一通知消息用于通知所述接收端刪除所述解壓縮表；第一刪除模塊，用于在接收到來自所述接收端的成功刪除響應(yīng)后，刪除所述壓縮表。

可選地，所述裝置還包括：第二刪除模塊，用于在按照預(yù)先與接收端協(xié)商的壓縮方式對待發(fā)送給所述接收端的所述RTP報文進(jìn)行壓縮之后，并且在壓縮RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)壓縮RTP報文失敗的時間超過第二閾值后，刪除所述壓縮表；第三發(fā)送模塊，用于向所述接收端發(fā)送第二通知消息，其中，所述第二通知消息用于通知所述接收端刪除所述解壓縮表。

可選地，所述裝置還包括：第二接收模塊，用于在通過衛(wèi)星將壓縮后的RTP報文傳輸給所述接收端之后，接收來自所述接收端的用于通知刪除所述壓縮表的第三通知消息；第三刪除模塊，用于根據(jù)所述第三通知消息刪除所述壓縮表。

可選地，所述第三通知消息包括以下至少之一：所述接收端在解壓縮壓縮后的RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)解壓縮壓縮后的RTP報文失敗的時間超過第二閾值的情況下發(fā)送的通知消息；所述接收端在接收到攜帶掛斷指令的第二實時傳輸控制協(xié)議RTCP報文后發(fā)送的通知消息。

可選地，所述報文處理裝置位于第一網(wǎng)關(guān)或終端中，所述接收端包括第二網(wǎng)關(guān)；或者，所述報文處理裝置位于第二網(wǎng)關(guān)中，所述接收端包括第一網(wǎng)關(guān)或終端。

根據(jù)本發(fā)明的另一方面，提供了一種報文處理裝置，包括：第三接收模塊，用于接收發(fā)送端通過衛(wèi)星發(fā)送的壓縮后的實時傳輸協(xié)議RTP報文；解壓縮模塊，用于根據(jù)與所述發(fā)送端協(xié)商的解壓縮方式解壓縮所述壓縮后的RTP報文。

可選地，所述裝置還包括第二協(xié)商模塊，用于通過如下方式與所述發(fā)送端協(xié)商所述解壓縮方式：接收來自所述發(fā)送端的壓縮表；根據(jù)所述壓縮表建立用于解壓縮所述壓縮后的RTP報文的解壓縮表。

可選地，所述裝置還包括：第四接收模塊，用于在根據(jù)所述壓縮表建立用于解壓縮所述壓縮后的RTP報文的所述解壓縮表之后，接收來自所述發(fā)送端的第四通知消息；第四刪除模塊，用于根據(jù)所述第四通知消息刪除所述解壓縮表。

可選地，所述第四通知消息包括以下至少之一：所述發(fā)送端在壓縮待發(fā)送過來的RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)壓縮待發(fā)送過來的RTP報文失敗的時間超過第二閾值的情況下發(fā)送的通知消息；所述發(fā)送端在接收到攜帶掛斷指令的第一實時傳輸控制協(xié)議RTCP報文后發(fā)送的通知消息。

可選地，當(dāng)所述第四通知消息包括所述發(fā)送端在接收到攜帶掛斷指令的所述第一RTCP報文后發(fā)送的通知消息時，所述裝置還包括：第四發(fā)送模塊，用于在根據(jù)所述第四通知消息刪除所述解壓縮表之后，向所述發(fā)送端發(fā)送成功刪除響應(yīng)，其中，所述成功刪除響應(yīng)用于指示所述發(fā)送端刪除所述壓縮表。

可選地，所述裝置還包括：第五接收模塊，用于在接收來自所述發(fā)送端的所述壓縮表之后，接收攜帶掛斷指令的第二實時傳輸控制協(xié)議RTCP報文；第五發(fā)送模塊，用于向所述發(fā)送端發(fā)送第五通知消息，其中，所述第五通知消息用于通知所述發(fā)送端刪除所述壓縮表；第五刪除模塊，用于在接收到來自所述發(fā)送端的成功刪除響應(yīng)后，刪除所述解壓縮表。

可選地，所述裝置還包括：處理模塊，用于在根據(jù)與所述發(fā)送端協(xié)商的所述解壓縮方式解壓縮所述壓縮后的RTP報文之后，并且解壓縮壓縮后的RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)解壓縮壓縮后的RTP報文失敗的時間超過第二閾值后，刪除所述解壓縮表，并向所述發(fā)送端發(fā)送第六通知消息，其中，所述第六通知消息用于通知所述發(fā)送端刪除所述壓縮表。

可選地，所述報文處理裝置位于第二網(wǎng)關(guān)中，所述發(fā)送端包括第一網(wǎng)關(guān)或終端；或者，所述報文處理裝置位于第一網(wǎng)關(guān)或終端中，所述發(fā)送端包括第二網(wǎng)關(guān)。

通過本發(fā)明，采用按照與接收端協(xié)商的壓縮方式對待發(fā)送給所述接收端的實時傳輸協(xié)議RTP報文進(jìn)行壓縮；在壓縮成功后，通過衛(wèi)星將壓縮后的RTP報文發(fā)送給所述接 收端。解決了相關(guān)技術(shù)中存在的語音通信在衛(wèi)星通訊領(lǐng)域上的帶寬利用率不足的問題，進(jìn)而達(dá)到了提高語音通信在衛(wèi)星通訊領(lǐng)域上的帶寬利用率，節(jié)省帶寬資源的效果。

附圖說明

此處所說明的附圖用來提供對本發(fā)明的進(jìn)一步理解，構(gòu)成本申請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當(dāng)限定。在附圖中：

圖1是根據(jù)本發(fā)明實施例的報文處理方法的流程圖；

圖2是根據(jù)本發(fā)明實施例的報文處理方法的流程圖；

圖3是根據(jù)本發(fā)明實施例的語音呼叫以及掛斷過程的交互流程圖；

圖4是根據(jù)本發(fā)明實施例的衛(wèi)星通信傳輸場景示意圖；

圖5是根據(jù)本發(fā)明實施例的RTP報文的判斷流程圖；

圖6是根據(jù)本發(fā)明實施例的ROHC自定義協(xié)商報文封裝格式示意圖；

圖7是根據(jù)本發(fā)明實施例的UE直接接入衛(wèi)星通信場景；

圖8是根據(jù)本發(fā)明實施例的CUDP自定義協(xié)商報文封裝格式示意圖；

圖9是根據(jù)本發(fā)明實施例的第一種報文處理裝置的結(jié)構(gòu)框圖；

圖10是根據(jù)本發(fā)明實施例的第一種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖一；

圖11是根據(jù)本發(fā)明實施例的第一種報文處理裝置中第一協(xié)商模塊102的結(jié)構(gòu)框圖；

圖12是根據(jù)本發(fā)明實施例的第一種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖二；

圖13是根據(jù)本發(fā)明實施例的第一種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖三；

圖14是根據(jù)本發(fā)明實施例的第一種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖四；

圖15是根據(jù)本發(fā)明實施例的第二種報文處理裝置的結(jié)構(gòu)框圖；

圖16是根據(jù)本發(fā)明實施例的第二種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖一；

圖17是根據(jù)本發(fā)明實施例的第二種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖二；

圖18是根據(jù)本發(fā)明實施例的第二種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖三；

圖19是根據(jù)本發(fā)明實施例的第二種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖四；

圖20是根據(jù)本發(fā)明實施例的第二種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖五。

具體實施方式

下文中將參考附圖并結(jié)合實施例來詳細(xì)說明本發(fā)明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互組合。

需要說明的是，本發(fā)明的說明書和權(quán)利要求書及上述附圖中的術(shù)語“第一”、“第二”等是用于區(qū)別類似的對象，而不必用于描述特定的順序或先后次序。

在本實施例中提供了一種報文處理方法，圖1是根據(jù)本發(fā)明實施例的報文處理方法的流程圖，如圖1所示，該流程包括如下步驟：

步驟S102，按照與接收端協(xié)商的壓縮方式對待發(fā)送給接收端的實時傳輸協(xié)議RTP報文進(jìn)行壓縮；

步驟S104，在壓縮成功后，通過衛(wèi)星將壓縮后的RTP報文發(fā)送給上述接收端。

從上述步驟可知，在向接收端發(fā)送RTP報文時，是首先對該RTP報文進(jìn)行了壓縮(由于RTP報文的報文頭會占用較大的帶寬，對RTP報文進(jìn)行壓縮時，可以僅對RTP報文的IP頭、UDP頭和RTP頭進(jìn)行壓縮)，然后將壓縮后的RTP報文發(fā)送給了接收端，其中，壓縮后的RTP報文的大小相對于原始的未壓縮的RTP報文的而言，會小很多，這樣，便可以減少帶寬的占用，從而實現(xiàn)了在一定的帶寬上發(fā)送更多的RTP報文的目的，提高了帶寬的利用率，解決了相關(guān)技術(shù)中存在的語音通信在衛(wèi)星通訊領(lǐng)域上的帶寬利用率不足的問題，進(jìn)而達(dá)到了提高語音通信在衛(wèi)星通訊領(lǐng)域上的帶寬利用率，節(jié)省帶寬資源的效果。

在一個可選的實施例中，可以通過如下方式與接收端協(xié)商壓縮方式：根據(jù)待發(fā)送給接收端的RTP報文的相關(guān)信息建立壓縮表，其中，該壓縮表中攜帶當(dāng)前選擇的壓縮方式的標(biāo)識和上述RTP報文的相關(guān)信息，當(dāng)該當(dāng)前選擇的壓縮方式為可靠頭壓縮(Robust Header Compression，簡稱為ROCH)或配置壓縮實時協(xié)議(Configuring Compressed Real-Time Protocol，簡稱為CRTP)時，上述相關(guān)信息包括RTP報文的源互聯(lián)網(wǎng)協(xié)議IP地址、目的IP地址、用戶數(shù)據(jù)協(xié)議UDP源端口、UDP目的端口和RTP頭；或者，當(dāng)上述壓縮方式為配置壓縮用戶數(shù)據(jù)協(xié)議(Configuring Compressed User Date Protocol，簡稱為CUDP)時，上述相關(guān)信息包括RTP報文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；將建立的上述壓縮表發(fā)送給接收端，其中，該壓縮表用于指示接收端建立與壓縮表對應(yīng)的解壓縮表。其中，接收端在成功建立了解壓縮表后，可以再返回一個建立OK的響應(yīng)消息。需要說明的是，上述的幾種壓縮方式僅是示例，還可以采用其他的壓縮方式，同樣地，當(dāng)采用其他的壓縮方式時，需要建立與該其他的壓縮方式對應(yīng)的壓縮表，不同的壓縮方式對應(yīng)的壓縮表中的內(nèi)容可以是不同的。在上述的協(xié)商方式完成之后，兩端便可以采用協(xié)商的方式進(jìn)行RTP報文的壓縮、解壓縮操作了。

在一個可選的實施例中，上述RTP報文的相關(guān)信息可以通過如下方式獲?。号袛嘟邮盏降拇l(fā)送給接收端的報文是否是RTP報文；在判斷結(jié)果為該報文是RTP報文的情況下，提取上述報文的相關(guān)信息作為RTP報文的相關(guān)信息。其中，該待發(fā)送給接收 端的報文可以是需要發(fā)送給接收端的第一個RTP報文，并且，為了避免延時過大，該第一個RTP報文可以不經(jīng)過壓縮直接發(fā)送給接收端。

其中，判斷報文是否是RTP報文的方式可以有多種判斷方式，下面對本發(fā)明實施例中提出的判斷方法進(jìn)行說明：判斷接收到的待發(fā)送給所述接收端的所述報文是否是RTP報文包括：判斷待發(fā)送給接收端的報文是否是UDP報文；當(dāng)確定該報文是UDP報文后，判斷該報文的UDP數(shù)據(jù)幀的字節(jié)數(shù)是否大于預(yù)定數(shù)量(例如，該預(yù)定數(shù)量為12個字節(jié)，即，是否大于RTP報文固定頭的長度)，如果大于預(yù)定數(shù)量，則判斷報文的UDP載荷中的預(yù)定位(例如，前兩位)是否為預(yù)定值(例如，0x10，即，是否與現(xiàn)行的RTP版本號相同)；當(dāng)確定該報文的UDP載荷中的預(yù)定位是預(yù)定值時，判斷報文的有效載荷PAYLOAD的編碼格式是否為RTP的編碼格式；當(dāng)確定該報文的PAYLOAD為RTP的編碼格式時，確定該報文是RTP報文。采用本發(fā)明實施例中的判斷方案，即通過判斷編碼格式是否是RTP的編碼格式來確定報文是否是RTP報文，能夠簡化判斷步驟，提高判斷準(zhǔn)確度。并且，在后續(xù)的過程中，當(dāng)接收到需要發(fā)送給接收端的報文后，也可以按照上述方法判斷接收到的報文是否是RTP報文，當(dāng)確定是時，再對確定是RTP的報文按照上述的實施例中的方法進(jìn)行壓縮，然后，發(fā)送壓縮后的RTP報文。

執(zhí)行上述操作的主體可以是發(fā)送端，壓縮表和解壓縮表在建立之后，發(fā)送端和接收端也可以對壓縮表和解壓縮表進(jìn)行刪除或更新操作，在一個可選的實施例中，在將建立的壓縮表發(fā)送給接收端之后，上述方法還包括：接收攜帶掛斷指令的第一實時傳輸控制協(xié)議RTCP報文；向接收端發(fā)送第一通知消息，其中，該第一通知消息用于通知接收端刪除解壓縮表；在接收到來自上述接收端的成功刪除響應(yīng)后，刪除壓縮表。其中，該RTCP報文中的特定字段可以被設(shè)置為BYE，該被設(shè)置為BYE的特定字段可以是上述的掛斷指令。

在一個可選的實施例中，在按照預(yù)先與接收端協(xié)商的壓縮方式對待發(fā)送給接收端的RTP報文進(jìn)行壓縮之后，該方法還包括：在壓縮RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)壓縮RTP報文失敗的時間超過第二閾值后，刪除上述壓縮表；向接收端發(fā)送第二通知消息，其中，該第二通知消息用于通知接收端刪除解壓縮表。其中，在該實施例中，可以在壓縮RTP報文失敗后即刪除壓縮表，也可以當(dāng)壓縮RTP報文失敗的次數(shù)超過預(yù)定次數(shù)(該預(yù)定次數(shù)可以大于1)后再刪除壓縮表，或者，也可以在持續(xù)壓縮RTP報文失敗的時間超過一定值的時候刪除壓縮表，然后再通知接收端刪除解壓縮表。

在上述實施例中描述了壓縮表和解壓縮表的刪除是由發(fā)送端(即，執(zhí)行上述操作的一端)觸發(fā)的，當(dāng)然，壓縮表和解壓縮表的刪除也可以是由接收端觸發(fā)的，在一個可選的實施例中，在通過衛(wèi)星將壓縮后的RTP報文傳輸給接收端之后，該方法還包括：接收來自接收端的用于通知刪除壓縮表的第三通知消息；根據(jù)該第三通知消息刪除壓縮表。

在一個可選的實施例中，上述第三通知消息可以包括以下至少之一：接收端在解壓縮壓縮后的RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)解壓縮壓縮后的RTP報文失敗 的時間超過第二閾值的情況下發(fā)送的通知消息；上述接收端在接收到攜帶掛斷指令的第二實時傳輸控制協(xié)議RTCP報文后發(fā)送的通知消息。同樣的，接收端在解壓縮壓縮后的RTP報文失敗的情況下發(fā)送的通知消息可以是在接收端解壓一次失敗后即發(fā)送的通知消息，也可以是接收端解壓失敗的次數(shù)超過預(yù)定次數(shù)后發(fā)送的通知消息，或者，也可以是接收端在持續(xù)解壓縮失敗的時間超過一定值后發(fā)送的通知消息，并且，接收端在發(fā)送通知消息之前，可以先刪除接收端中的解壓縮表。

在上述實施例中，當(dāng)發(fā)送端刪除了壓縮表、接收端刪除了解壓縮表后，發(fā)送端和接收端可以重新發(fā)起協(xié)商建立壓縮表解壓縮表的流程。

在本實施例中還提供了一種報文處理方法，圖2是根據(jù)本發(fā)明實施例的報文處理方法的流程圖，如圖2所示，該流程包括如下步驟：

步驟S202，接收發(fā)送端通過衛(wèi)星發(fā)送的壓縮后的實時傳輸協(xié)議RTP報文；

步驟S204，根據(jù)與上述發(fā)送端協(xié)商的解壓縮方式解壓縮壓縮后的RTP報文。

由上述步驟可知，接收的RTP報文是壓縮后的RTP報文，即，發(fā)送端在發(fā)送RTP報文時，是首先對該RTP報文進(jìn)行了壓縮，然后再發(fā)送壓縮后的RTP報文，其中，壓縮后的RTP報文的大小相對于原始的未壓縮的RTP報文的而言，會小很多，這樣，便可以減少帶寬的占用，從而實現(xiàn)了在一定的帶寬上發(fā)送更多的RTP報文的目的，提高了帶寬的利用率，解決了相關(guān)技術(shù)中存在的語音通信在衛(wèi)星通訊領(lǐng)域上的帶寬利用率不足的問題，進(jìn)而達(dá)到了提高語音通信在衛(wèi)星通訊領(lǐng)域上的帶寬利用率，節(jié)省帶寬資源的效果。

在一個可選的實施例中，可以通過如下方式與發(fā)送端協(xié)商上述解壓縮方式：接收來自發(fā)送端的壓縮表；根據(jù)該壓縮表建立用于解壓縮上述壓縮后的RTP報文的解壓縮表。需要說明的是，上述的壓縮表里可以標(biāo)識采用的是何種壓縮方式(例如，可以是ROCH壓縮方式或者，CUDP壓縮方式)，不同的壓縮方式對應(yīng)的壓縮表中的內(nèi)容可以是不同的。在上述的協(xié)商方式完成之后，兩端便可以采用協(xié)商的方式進(jìn)行RTP報文的壓縮、解壓縮操作了。

其中，執(zhí)行上述操作的主體可以是接收端，壓縮表和解壓縮表在建立之后，發(fā)送端和接收端也可以對壓縮表和解壓縮表進(jìn)行刪除或更新操作，在一個可選的實施例中，在根據(jù)上述壓縮表建立用于解壓縮所述壓縮后的RTP報文的所述解壓縮表之后，所述方法還包括：接收來自發(fā)送端的第四通知消息；根據(jù)該第四通知消息刪除上述解壓縮表。

在一個可選的實施例中，上述第四通知消息可以包括以下至少之一：發(fā)送端在壓縮待發(fā)送過來的RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)壓縮待發(fā)送過來的RTP報文失敗的時間超過第二閾值的情況下發(fā)送的通知消息；發(fā)送端在接收到攜帶掛斷指令的第一實時傳輸控制協(xié)議RTCP報文后發(fā)送的通知消息?？蛇x地，發(fā)送端在壓縮RTP報文失 敗的情況下發(fā)送的通知消息可以是在發(fā)送端壓縮一次失敗后即發(fā)送的通知消息，也可以是發(fā)送端壓縮失敗的次數(shù)超過預(yù)定次數(shù)后發(fā)送的通知消息，或者，也可以是發(fā)送端在持續(xù)壓縮失敗的時間超過一定值后發(fā)送的通知消息，并且，發(fā)送端在發(fā)送通知消息之前，可以先刪除發(fā)送端中的壓縮表；從上述的描述中可知，RTCP報文中可以攜帶掛斷指令，其攜帶方式可以是在RTCP中預(yù)定字段被設(shè)置為BYE。

在一個可選的實施例中，當(dāng)上述第四通知消息包括發(fā)送端在接收到攜帶掛斷指令的第一RTCP報文后發(fā)送的通知消息時，在根據(jù)上述第四通知消息刪除解壓縮表之后，上述方法還包括：向所述發(fā)送端發(fā)送成功刪除響應(yīng)，其中，該成功刪除響應(yīng)用于指示發(fā)送端刪除壓縮表。

在上述實施例中描述了壓縮表和解壓縮表的刪除是由發(fā)送端觸發(fā)的，當(dāng)然，壓縮表和解壓縮表的刪除也可以是由接收端觸發(fā)的，在一個可選的實施例中，在接收來自發(fā)送端的壓縮表之后，該方法還包括：接收攜帶掛斷指令的第二實時傳輸控制協(xié)議RTCP報文；向發(fā)送端發(fā)送第五通知消息，其中，該第五通知消息用于通知發(fā)送端刪除壓縮表；在接收到來自發(fā)送端的成功刪除響應(yīng)后，刪除上述解壓縮表。其中，RTCP報文中攜帶掛斷指令的攜帶方式可以是在RTCP中預(yù)定字段被設(shè)置為BYE。

在一個可選的實施例中，在根據(jù)與上述發(fā)送端協(xié)商的解壓縮方式解壓縮壓縮后的RTP報文之后，該方法還包括：當(dāng)解壓縮壓縮后的RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)解壓縮壓縮后的RTP報文失敗的時間超過第二閾值后，刪除上述解壓縮表，并向發(fā)送端發(fā)送第六通知消息，其中，該第六通知消息用于通知發(fā)送端刪除壓縮表。其中，在該實施例中，可以在解壓縮RTP報文失敗后即刪除解壓縮表，也可以當(dāng)解壓縮RTP報文失敗的次數(shù)超過預(yù)定次數(shù)(該預(yù)定次數(shù)可以大于1)后再刪除解壓縮表，或者，也可以在持續(xù)解壓縮RTP報文失敗的時間超過一定值的時候刪除解壓縮表，然后再通知發(fā)送端刪除壓縮表。

在上述實施例中，當(dāng)發(fā)送端刪除了壓縮表、接收端刪除了解壓縮表后，發(fā)送端和接收端可以重新發(fā)起協(xié)商建立壓縮表解壓縮表的流程。

下面以上述的發(fā)送端為網(wǎng)關(guān)GW1，接收端為網(wǎng)關(guān)GW2為例，對本發(fā)明的整體流程進(jìn)行說明：

圖3是根據(jù)本發(fā)明實施例的語音呼叫以及掛斷過程的交互流程圖，如圖3所示，該流程包括如下步驟：

步驟S301，當(dāng)主叫方的用戶設(shè)備(User Equipment，簡稱為UE)(以下簡稱為UE)需要發(fā)起語音呼叫被叫方時，該UE向IP對媒體子系統(tǒng)(IP multimedia subsystem，簡稱為IMS)發(fā)起語音呼叫；

步驟S302，當(dāng)IMS確定允許UE進(jìn)行語音呼叫時，向UE返回一個語音呼叫成功的 響應(yīng)；

步驟S303，UE向UE側(cè)的網(wǎng)關(guān)GW1發(fā)送語音報文(對應(yīng)于上述的RTP報文)；

步驟S304，GW1確定壓縮方式，并根據(jù)該語音報文建立該壓縮方式下的壓縮表，其建立過程如上述的實施例所述，在此不再陳述；并且，GW1將該語音報文和建立的壓縮表發(fā)送給被叫側(cè)UE的網(wǎng)關(guān)GW2，GW2根據(jù)壓縮表建立于該壓縮表對應(yīng)的解壓縮表；

步驟S305，GW1與GW2建立壓縮會話；

步驟S306，GW2向GW1返回建立壓縮會話成功消息；

步驟S307，GW2將GW1發(fā)送過來的語音報文發(fā)送給IMS；

步驟S308，UE向GW1發(fā)送語音報文；

步驟S309，GW1對UE發(fā)送過來的語音報文按照上述確定的壓縮方式進(jìn)行壓縮，并將壓縮后的語音報文發(fā)送到GW2；

步驟S310，GW2對接收到的壓縮的語音報文進(jìn)行解壓縮，并將解壓縮后的語音報文發(fā)送給IMS；

步驟S311，GW2接收到被叫側(cè)UE發(fā)送的語音報文，并且，GW2按照和上述相同的方式和GW1協(xié)商壓縮解壓縮方式；

步驟S312，GW2按照協(xié)商的壓縮方式壓縮被叫側(cè)UE發(fā)送的語音報文，并發(fā)送給GW1；

步驟S313，GW1對接收的壓縮后的來自被叫側(cè)UE的語音報文進(jìn)行解壓縮，并發(fā)送給主叫方的UE；

步驟S314，主叫方UE確定需要掛斷此次語音通話，會向IMS發(fā)送掛斷語音呼叫的通知；

步驟S315，GW1通知GW2刪除壓縮會話；

步驟S316，GW2向GW1返回刪除壓縮會話成功的消息；

步驟S317，IMS向主叫方UE發(fā)送你語音呼叫響應(yīng)消息，至此，語音通話結(jié)束。

下面結(jié)合具體應(yīng)用場景對本發(fā)明進(jìn)行說明：

實施實例1：

圖4是根據(jù)本發(fā)明實施例的衛(wèi)星通信傳輸場景示意圖，如圖4所示，在本實施方案 中使用ROHC壓縮(CRTP壓縮和ROHC壓縮是類似的，在此，以ROHC為例進(jìn)行說明)的方法對語音報文進(jìn)行壓縮，ROHC通常用于無線通信的空中接口，在本例中用在衛(wèi)星傳輸語音壓縮的場景。

流程部分的處理步驟如下：

建立連接：

圖5是根據(jù)本發(fā)明實施例的RTP報文的判斷流程圖，GW1在收到報文后，可以按照圖5所示的流程判斷是否為RTP報文，其判斷流程包括如下步驟：

步驟S501，包過濾模塊(該過濾模塊可以是發(fā)送端或接收端中的一個模塊)對所有收到的報文分析；

步驟S502，包過濾模塊判斷是否是UDP報文，如果是UDP報文，轉(zhuǎn)至步驟S503，否則，轉(zhuǎn)至步驟S512；

步驟S503，判斷報文的IP地址(包括源IP地址和目的IP地址)和端口號(包括UDP源端口和UDP目的端口)是否能在ROHC壓縮解壓縮實例中查找到，如果能查找到，則認(rèn)為是已建立好的壓縮會話，轉(zhuǎn)至步驟S510，否則，轉(zhuǎn)至步驟S504；

步驟S504，判斷UDP數(shù)據(jù)幀是否大于12個字節(jié)，如果判斷結(jié)果為大于12個字節(jié)，則轉(zhuǎn)至步驟S505，否則，轉(zhuǎn)至步驟S512；

步驟S505，判斷UDP載荷前兩位是否為0x10(RTP/RTCP為2)，如果是轉(zhuǎn)至步驟S506，否則，轉(zhuǎn)至部署S512；

步驟S506，判斷PAYLOAD載荷是否為RTP或RTCP的編碼格式，判斷結(jié)果為是，轉(zhuǎn)至步驟S506，否則，轉(zhuǎn)至步驟S512；

步驟S507，判斷一個會話中同步信源標(biāo)識符SSRC是否不變，判斷結(jié)果為是，轉(zhuǎn)至步驟S508，否則，轉(zhuǎn)至步驟S512；

步驟S508，循環(huán)判斷3次，判斷SSRC是否一致，若為是，轉(zhuǎn)至步驟S509，否則，轉(zhuǎn)至步驟S512；

步驟S509，連續(xù)3次條件都滿足，則判斷認(rèn)為是RTP或者RTCP報文，如果是RTP報文跳轉(zhuǎn)到步驟S511；

步驟S510，壓縮報文；

步驟S511，記錄IP地址UDP端口號RTP頭中的SSRC標(biāo)識，創(chuàng)建ROHC壓縮解壓縮實例，構(gòu)造一個報文，將上面記錄的信息按照圖6所示的格式(當(dāng)采用CRTP壓縮時，格式與圖6所示類似，區(qū)別在于標(biāo)識需要采用CRTP標(biāo)識)封裝后發(fā)送到GW2，其中，圖6是根據(jù)本發(fā)明實施例的ROHC自定義協(xié)商報文封裝格式示意圖，GW2在收 到后根據(jù)發(fā)過來的信息，創(chuàng)建壓縮解壓縮實例，同時按照圖6的格式回復(fù)GW1，轉(zhuǎn)步驟S513；

步驟S512，確定不是RTP和RTCP報文，繼續(xù)對接收到的報文進(jìn)行檢測；

步驟S513，GW1收到后啟用ROHC壓縮，包過濾模塊在收到RTP報文后在ROHC壓縮實例表中查找是否有對應(yīng)的表項，如果有，則開始對RTP報文開始壓縮，基于ROHC實例創(chuàng)建壓縮解壓縮會話，壓縮RTP報文，包括IP頭+UDP頭+RTP頭，GW2處理類似GW1網(wǎng)關(guān)操作。

其中，上述的步驟S507-S509是可選的，當(dāng)針對單一的報文進(jìn)行判斷時，可以不用進(jìn)行循環(huán)3次的判斷。

下面對連接關(guān)閉進(jìn)行說明：

GW1或者GW2收到RTCP報文，如果是掛斷報文，即RTCP報文的相應(yīng)的字段被設(shè)置為BYE，則認(rèn)為是刪除RTP對應(yīng)的ROHC壓縮解壓縮會話，根據(jù)RTCP頭中的IP地址、UDP端口號、SSRC標(biāo)識查找ROHC壓縮解壓縮表，如果能查到，刪除對應(yīng)的RTP壓縮解壓縮會話，同時按照圖6的格式通知對方刪除對應(yīng)的壓縮解壓縮會話。

下面對異常保護(hù)進(jìn)行說明：

GW1或者GW2連續(xù)一段時間內(nèi)ROHC解壓縮失敗后，刪除本端壓縮解壓縮表，同時通知對端刪除，重新發(fā)起協(xié)商建立壓縮解壓縮表。

實施實例2：

圖7是根據(jù)本發(fā)明實施例的UE直接接入衛(wèi)星通信場景。下面以上述UE為手機為例，對本發(fā)明進(jìn)行說明。

在本實施方案中同樣使用ROHC壓縮(同樣地，也可以采用CRTP壓縮方式，在該實施例中，以ROHC壓縮方式為例進(jìn)行說明)的方法對語音報文進(jìn)行壓縮，手機和GW2上駐留壓縮和包過濾模塊。

下面對連接建立過程進(jìn)行說明：

步驟S1，手機通過衛(wèi)星接入后，通過網(wǎng)絡(luò)發(fā)起語音呼叫后，包過濾模塊監(jiān)聽到手機發(fā)送的報文是RTP語音報文；

步驟S2，壓縮模塊記錄IP地址UDP端口號RTP頭中的SSRC標(biāo)識，創(chuàng)建ROHC壓縮解壓縮實例，構(gòu)造一個報文，將上面記錄的信息按照圖5的格式封裝后發(fā)送到GW2，GW2在收到后根據(jù)發(fā)過來的信息，創(chuàng)建壓縮解壓縮實例，同時按照圖6的格式回復(fù)給手機；

步驟S3，手機收到來自GW2的創(chuàng)建壓縮解壓縮成功的消息后，啟動ROHC壓縮，轉(zhuǎn)到S4；

步驟S4，GW2或者手機上包過濾模塊在監(jiān)聽到發(fā)送的RTP語音報文時，則在ROHC壓縮實例表中查找是否有對應(yīng)的表項，如果有則開始對RTP報文開始壓縮，基于ROHC實例創(chuàng)建壓縮解壓縮會話，壓縮RTP報文頭，包括IP頭+UDP頭+RTP頭。

下面對連接關(guān)閉進(jìn)行說明：

手機或者GW2收到RTCP報文，如果是掛斷報文，即RTCP報文的相應(yīng)的字段被設(shè)置為BYE，則認(rèn)為是刪除RTP對應(yīng)的ROHC壓縮解壓縮會話，根據(jù)RTCP頭中的IP地址、UDP端口號、SSRC標(biāo)識查找ROHC壓縮解壓縮表，如果能查到，刪除對應(yīng)的RTP壓縮解壓縮會話，同時按照圖6的格式通知對方刪除對應(yīng)的壓縮解壓縮會話。

下面對異常保護(hù)進(jìn)行說明：

手機或者GW2連續(xù)一段時間內(nèi)ROHC解壓縮失敗后，刪除本端壓縮解壓縮表，同時通知對端刪除，重新發(fā)起協(xié)商建立壓縮解壓縮表。

實施實例3：

該實施例以圖4所示的衛(wèi)星通信場景為例進(jìn)行說明：

在本實施方案中使用CUDP壓縮的方法對語音報文進(jìn)行壓縮，GW1和GW2上駐留壓縮和包過濾模塊。

下面對建立連接過程進(jìn)行說明：

步驟S1，GW1在收到報文后按照圖5所示的流程判斷是否為RTP報文，包過濾模塊對所有收到的報文分析，先判斷是否UDP報文，如果是UDP報文，判斷IP地址和端口號是否能在CUDP壓縮解壓縮實例中查找到，如果能查找到，則認(rèn)為是已建立好的壓縮會話，如果查找不到則繼續(xù)判斷UDP數(shù)據(jù)幀是否大于12個字節(jié)，如果是判斷UDP載荷前兩位是否為0x10(RTP/RTCP為2)，如果是判斷PAYLOAD載荷是否為RTP或RTCP的編碼格式，循環(huán)判斷3次，判斷SSRC是否一致，連續(xù)3次條件都滿足，則判斷認(rèn)為是RTP或者RTCP報文，如果是RTP報文跳轉(zhuǎn)到第二步；

S2，記錄IP地址UDP端口號，創(chuàng)建CUDP壓縮解壓縮通道表，構(gòu)造一個報文，將上面記錄的信息按照圖8的格式封裝后發(fā)送到GW2，GW2在收到后根據(jù)發(fā)過來的信息，創(chuàng)建壓縮解壓縮實例，同時按照圖8的格式回復(fù)GW1，其中，圖8是根據(jù)本發(fā)明實施例的CUDP自定義協(xié)商報文封裝格式示意圖；

S3，GW1收到后啟用CUDP壓縮，包過濾模塊在收到RTP報文后在CUDP壓縮通 道表中查找是否有對應(yīng)的表項，如果有則開始對RTP報文開始壓縮，壓縮RTP報文，GW2處理類似GW1網(wǎng)關(guān)操作。

下面對連接關(guān)閉進(jìn)行說明：

GW1或者GW2收到RTCP報文，如果是掛斷報文，即RTCP報文的相應(yīng)的字段被設(shè)置為BYE，則認(rèn)為是刪除RTP對應(yīng)的CUDP壓縮解壓縮會話，根據(jù)RTCP頭中的IP地址、UDP端口號查找CUDP壓縮解壓縮表，如果能查到，刪除對應(yīng)的RTP壓縮解壓縮會話，同時按照圖8的格式通知對方刪除對應(yīng)的壓縮解壓縮會話。

下面對異常保護(hù)進(jìn)行說明：

GW1或者GW2連續(xù)一段時間內(nèi)CUDP解壓縮失敗后，刪除本端壓縮解壓縮表，同時通知對端刪除，重新發(fā)起協(xié)商建立壓縮解壓縮表。

通過以上的實施方式的描述，本領(lǐng)域的技術(shù)人員可以清楚地了解到根據(jù)上述實施例的方法可借助軟件加必需的通用硬件平臺的方式來實現(xiàn)，當(dāng)然也可以通過硬件，但很多情況下前者是更佳的實施方式?；谶@樣的理解，本發(fā)明的技術(shù)方案本質(zhì)上或者說對現(xiàn)有技術(shù)做出貢獻(xiàn)的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品存儲在一個存儲介質(zhì)(如ROM/RAM、磁碟、光盤)中，包括若干指令用以使得一臺終端設(shè)備(可以是手機，計算機，服務(wù)器，或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個實施例所述的方法。

在本實施例中還提供了一種報文處理裝置，該裝置用于實現(xiàn)上述實施例及優(yōu)選實施方式，已經(jīng)進(jìn)行過說明的不再贅述。如以下所使用的，術(shù)語“模塊”可以實現(xiàn)預(yù)定功能的軟件和/或硬件的組合。盡管以下實施例所描述的裝置較佳地以軟件來實現(xiàn)，但是硬件，或者軟件和硬件的組合的實現(xiàn)也是可能并被構(gòu)想的。

圖9是根據(jù)本發(fā)明實施例的第一種報文處理裝置的結(jié)構(gòu)框圖，如圖9所示，該裝置包括壓縮模塊92和第一發(fā)送模塊94，下面對該裝置進(jìn)行說明。

壓縮模塊92，用于按照與接收端協(xié)商的壓縮方式對待發(fā)送給接收端的實時傳輸協(xié)議RTP報文進(jìn)行壓縮；第一發(fā)送模塊94，連接至上述壓縮模塊92，用于在壓縮成功后，通過衛(wèi)星將壓縮后的RTP報文發(fā)送給接收端。

圖10是根據(jù)本發(fā)明實施例的第一種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖一，如圖10所示，該裝置除包括圖9所示的所有模塊外，還包括第一協(xié)商模塊102，下面對該裝置進(jìn)行說明。

第一協(xié)商模塊102，連接至上述壓縮模塊92，用于通過如下方式與接收端協(xié)商上述壓縮方式：根據(jù)待發(fā)送給接收端的RTP報文的相關(guān)信息建立壓縮表，其中，該壓縮表中攜帶當(dāng)前選擇的壓縮方式的標(biāo)識和RTP報文的相關(guān)信息，當(dāng)該當(dāng)前選擇的壓縮方式 為可靠頭壓縮ROCH或配置壓縮實時協(xié)議CRTP時，上述相關(guān)信息包括RTP報文的源互聯(lián)網(wǎng)協(xié)議IP地址、目的IP地址、用戶數(shù)據(jù)協(xié)議UDP源端口、UDP目的端口和RTP頭；或者，當(dāng)上述壓縮方式為配置壓縮用戶數(shù)據(jù)協(xié)議CUDP時，上述相關(guān)信息包括RTP報文的源IP地址、目的IP地址、UDP源端口和UDP目的端口；將建立的上述壓縮表發(fā)送給接收端，其中，該壓縮表用于指示接收端建立與壓縮表對應(yīng)的解壓縮表。

圖11是根據(jù)本發(fā)明實施例的第一種報文處理裝置中第一協(xié)商模塊102的結(jié)構(gòu)框圖，如圖11所示，在獲取RTP報文的相關(guān)信息時，該第一協(xié)商模塊102包括判斷單元112和提取單元114，下面對該第一協(xié)商模塊102進(jìn)行說明。

判斷單元112，用于判斷接收到的待發(fā)送給接收端的報文是否是RTP報文；提取單元114，連接至上述判斷單元112，用于在判斷結(jié)果為報文是RTP報文的情況下，提取報文的相關(guān)信息作為RTP報文的相關(guān)信息。

在一個可選的實施例中，上述判斷單元112可以通過如下方式判斷接收到的待發(fā)送給接收端的報文是否是RTP報文：判斷待發(fā)送給接收端的報文是否是UDP報文；當(dāng)確定上述報文是UDP報文后，判斷報文的UDP數(shù)據(jù)幀的字節(jié)數(shù)是否大于預(yù)定數(shù)量，如果大于預(yù)定數(shù)量，則判斷報文的UDP載荷中的預(yù)定位是否為預(yù)定值；當(dāng)確定報文的UDP載荷中的預(yù)定位是預(yù)定值時，判斷報文的有效載荷PAYLOAD的編碼格式是否為RTP的編碼格式；當(dāng)確定該報文的PAYLOAD為RTP的編碼格式時，確定該報文是RTP報文。

圖12是根據(jù)本發(fā)明實施例的第一種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖二，如圖12所示，該裝置除包括圖10所示的所有模塊外，還包括第一接收模塊122、第二發(fā)送模塊124和第一刪除模塊126，下面對該裝置進(jìn)行說明。圖12僅是一種示例，第一接收模塊122還可以連接至上述壓縮模塊92。

第一接收模塊122，連接至上述第一發(fā)送模塊94，用于在將建立的壓縮表發(fā)送給接收端之后，接收攜帶掛斷指令的第一實時傳輸控制協(xié)議RTCP報文；第二發(fā)送模塊124，連接至上述第一接收模塊122，用于向接收端發(fā)送第一通知消息，其中，該第一通知消息用于通知接收端刪除解壓縮表；第一刪除模塊126，連接至上述第二發(fā)送模塊124，用于在接收到來自接收端的成功刪除響應(yīng)后，刪除上述壓縮表。

圖13是根據(jù)本發(fā)明實施例的第一種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖三，如圖13所示，該裝置除包括圖10所示的所有模塊外，還包括第二刪除模塊132和第三發(fā)送模塊134，下面對該裝置進(jìn)行說明。圖13僅是一種示例，第二刪除模塊132還可以連接至上述壓縮模塊92。

第二刪除模塊132，連接至上述第一發(fā)送模塊94，用于在按照預(yù)先與接收端協(xié)商的壓縮方式對待發(fā)送給接收端的RTP報文進(jìn)行壓縮之后，并且在壓縮RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)壓縮RTP報文失敗的時間超過第二閾值后，刪除上述壓縮表； 第三發(fā)送模塊134，連接至上述第二刪除模塊132，用于向接收端發(fā)送第二通知消息，其中，該第二通知消息用于通知接收端刪除上述解壓縮表。

圖14是根據(jù)本發(fā)明實施例的第一種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖四，如圖14所示，該裝置除包括圖10所示的所有模塊外，還包括第二接收模塊142和第三刪除模塊144，下面對該裝置進(jìn)行說明。圖14僅是一種示例，第二接收模塊142還可以連接至上述壓縮模塊92。

第二接收模塊142，連接至上述第一發(fā)送模塊94，用于在通過衛(wèi)星將壓縮后的RTP報文傳輸給接收端之后，接收來自上述接收端的用于通知刪除壓縮表的第三通知消息；第三刪除模塊144，連接至上述第二接收模塊142，用于根據(jù)上述第三通知消息刪除壓縮表。

在一個可選的實施例中，上述第三通知消息包括以下至少之一：接收端在解壓縮壓縮后的RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)解壓縮壓縮后的RTP報文失敗的時間超過第二閾值的情況下發(fā)送的通知消息；接收端在接收到攜帶掛斷指令的第二實時傳輸控制協(xié)議RTCP報文后發(fā)送的通知消息。

在一個可選的實施例中，上述報文處理裝置位于第一網(wǎng)關(guān)或終端中，接收端包括第二網(wǎng)關(guān)；或者，上述報文處理裝置位于第二網(wǎng)關(guān)中，接收端包括第一網(wǎng)關(guān)或終端。

在本發(fā)明實施例中還提供了一種報文處理裝置，圖15是根據(jù)本發(fā)明實施例的第二種報文處理裝置的結(jié)構(gòu)框圖，如圖15所示，該裝置包括第三接收模塊152和解壓縮模塊154，下面對該裝置進(jìn)行說明。

第三接收模塊152，用于接收發(fā)送端通過衛(wèi)星發(fā)送的壓縮后的實時傳輸協(xié)議RTP報文；解壓縮模塊154，連接至上述第三接收模塊152，用于根據(jù)與上述發(fā)送端協(xié)商的解壓縮方式解壓縮壓縮后的RTP報文。

圖16是根據(jù)本發(fā)明實施例的第二種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖一，如圖16所示，該裝置除包括圖15所示的所有模塊外，還包括第二協(xié)商模塊162，下面對該裝置進(jìn)行說明。

第二協(xié)商模塊162，連接至上述解壓縮模塊154，用于通過如下方式與發(fā)送端協(xié)商解壓縮方式：接收來自發(fā)送端的壓縮表；根據(jù)上述壓縮表建立用于解壓縮壓縮后的RTP報文的解壓縮表。

圖17是根據(jù)本發(fā)明實施例的第二種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖二，如圖17所示，該裝置除包括圖16所示的所有模塊外，還包括第四接收模塊172和第四刪除模塊174，下面對該裝置進(jìn)行說明。圖17僅是一種示例，第四接收模塊172還可以連接至上述第二協(xié)商模塊162。

第四接收模塊172，連接至上述解壓縮模塊154，用于在根據(jù)上述壓縮表建立用于 解壓縮壓縮后的RTP報文的所述解壓縮表之后，接收來自發(fā)送端的第四通知消息；第四刪除模塊174，連接至上述第四接收模塊172，用于根據(jù)上述第四通知消息刪除解壓縮表。

在一個可選的實施例中，上述第四通知消息包括以下至少之一：發(fā)送端在壓縮待發(fā)送過來的RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)壓縮待發(fā)送過來的RTP報文失敗的時間超過第二閾值的情況下發(fā)送的通知消息；上述發(fā)送端在接收到攜帶掛斷指令的第一實時傳輸控制協(xié)議RTCP報文后發(fā)送的通知消息。

圖18是根據(jù)本發(fā)明實施例的第二種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖三，如圖18所示，當(dāng)上述第四通知消息包括發(fā)送端在接收到攜帶掛斷指令的所述第一RTCP報文后發(fā)送的通知消息時，上述裝置還包括第四發(fā)送模塊182，下面對該裝置進(jìn)行說明。

第四發(fā)送模塊182，連接至上述第四刪除模塊174，用于在根據(jù)上述第四通知消息刪除解壓縮表之后，向發(fā)送端發(fā)送成功刪除響應(yīng)，其中，該成功刪除響應(yīng)用于指示發(fā)送端刪除壓縮表。

圖19是根據(jù)本發(fā)明實施例的第二種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖四，如圖19所示，該裝置除包括圖16所示的模塊外，還包括第五接收模塊192、第五發(fā)送模塊194和第五刪除模塊196，下面對該裝置進(jìn)行說明。圖19僅是一種示例，第五接收模塊192還可以連接至上述第二協(xié)商模塊162。

第五接收模塊192，連接至上述解壓縮模塊154，用于在接收來自發(fā)送端的壓縮表之后，接收攜帶掛斷指令的第二實時傳輸控制協(xié)議RTCP報文；第五發(fā)送模塊194，連接至上述第五接收模塊192，用于向發(fā)送端發(fā)送第五通知消息，其中，該第五通知消息用于通知發(fā)送端刪除壓縮表；第五刪除模塊196，連接至上述第五發(fā)送模塊194，用于在接收到來自上述發(fā)送端的成功刪除響應(yīng)后，刪除解壓縮表。

圖20是根據(jù)本發(fā)明實施例的第二種報文處理裝置的優(yōu)選結(jié)構(gòu)框圖五，如圖20所示，該裝置除包括圖16所示的模塊外，還包括處理模塊202，下面對該裝置進(jìn)行說明。圖20僅是一種示例，處理模塊202還可以連接至上述第二協(xié)商模塊162。

處理模塊202，連接至上述壓縮模塊154，用于在根據(jù)與發(fā)送端協(xié)商的解壓縮方式解壓縮壓縮后的RTP報文之后，并且解壓縮壓縮后的RTP報文失敗的次數(shù)超過第一閾值和/或連續(xù)解壓縮壓縮后的RTP報文失敗的時間超過第二閾值后，刪除上述解壓縮表，并向發(fā)送端發(fā)送第六通知消息，其中，該第六通知消息用于通知發(fā)送端刪除壓縮表。

在一個可選的實施例中，上述報文處理裝置位于第二網(wǎng)關(guān)中，發(fā)送端包括第一網(wǎng)關(guān)或終端；或者，上述報文處理裝置位于第一網(wǎng)關(guān)或終端中，發(fā)送端包括第二網(wǎng)關(guān)。

需要說明的是，上述各個模塊是可以通過軟件或硬件來實現(xiàn)的，對于后者，可以通 過以下方式實現(xiàn)，但不限于此：上述模塊均位于同一處理器中；或者，上述模塊分別位于多個處理器中。

本發(fā)明的實施例還提供了一種存儲介質(zhì)?？蛇x地，在本實施例中，上述存儲介質(zhì)可以被設(shè)置為存儲用于執(zhí)行以下步驟的程序代碼：

S11，按照與接收端協(xié)商的壓縮方式對待發(fā)送給接收端的實時傳輸協(xié)議RTP報文進(jìn)行壓縮；

S12，在壓縮成功后，通過衛(wèi)星將壓縮后的RTP報文發(fā)送給上述接收端。

可選地，存儲介質(zhì)還被設(shè)置為存儲用于執(zhí)行以下步驟的程序代碼：

S21，接收發(fā)送端通過衛(wèi)星發(fā)送的壓縮后的實時傳輸協(xié)議RTP報文；

S22，根據(jù)與上述發(fā)送端協(xié)商的解壓縮方式解壓縮壓縮后的RTP報文。

可選地，在本實施例中，上述存儲介質(zhì)可以包括但不限于：U盤、只讀存儲器(Read-Only Memory，簡稱為ROM)、隨機存取存儲器(RandomAccess Memory，簡稱為RAM)、移動硬盤、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。

可選地，在本實施例中，處理器根據(jù)存儲介質(zhì)中已存儲的程序代碼執(zhí)行上述各實施例中的各個步驟。

可選地，本實施例中的具體示例可以參考上述實施例及可選實施方式中所描述的示例，本實施例在此不再贅述。

采用本發(fā)明實施例中的方法和裝置，與現(xiàn)有技術(shù)相比，能夠節(jié)省一半以上的語音占用帶寬。

顯然，本領(lǐng)域的技術(shù)人員應(yīng)該明白，上述的本發(fā)明的各模塊或各步驟可以用通用的計算裝置來實現(xiàn)，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網(wǎng)絡(luò)上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現(xiàn)，從而，可以將它們存儲在存儲裝置中由計算裝置來執(zhí)行，并且在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件結(jié)合。

以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領(lǐng)域的技術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。