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

背景技術(shù)：

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

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

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

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

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

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

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

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

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

可選地，所述RTP報(bào)文的相關(guān)信息通過如下方式獲?。号袛嘟邮盏降拇l(fā)送給所述接收端的報(bào)文是否是RTP報(bào)文；在判斷結(jié)果為所述報(bào)文是RTP報(bào)文的情況下，提取所述報(bào)文的相關(guān)信息作為所述RTP報(bào)文的相關(guān)信息。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

附圖說明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

具體實(shí)施方式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

步驟S305，GW1與GW2建立壓縮會(huì)話；

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

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

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

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

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

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

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

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

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

步驟S315，GW1通知GW2刪除壓縮會(huì)話；

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

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

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

實(shí)施實(shí)例1：

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

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

建立連接：

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

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

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

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

步驟S504，判斷UDP數(shù)據(jù)幀是否大于12個(gè)字節(jié)，如果判斷結(jié)果為大于12個(gè)字節(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，判斷一個(gè)會(huì)話中同步信源標(biāo)識(shí)符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報(bào)文，如果是RTP報(bào)文跳轉(zhuǎn)到步驟S511；

步驟S510，壓縮報(bào)文；

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

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

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

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

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

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

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

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

實(shí)施實(shí)例2：

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

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

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

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

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

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

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

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

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

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

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

實(shí)施實(shí)例3：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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