專利名稱：一種消息傳輸方法及消息壓縮協(xié)商請求及處理裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，尤其涉及一種消息傳輸方法及消息壓縮協(xié)商請 求及處理裝置。
背景技術(shù)：
媒體資源控制協(xié)議(Media Resource Control Protocol, MRCP )是一項新興 的標(biāo)準(zhǔn)，用于管理分布式系統(tǒng)架構(gòu)上的語音資源服務(wù)器，主要給客戶端提供一 種控制諸如語音合成和語音識別等服務(wù)器資源的通用機制。獨立軟件商和應(yīng)用 開發(fā)商僅需面向MRCP接口撰寫程序，而無需顧及語音識別和其電話應(yīng)用方 面的差異，應(yīng)用程序僅僅撰寫一次便可以部署在任何支持這個標(biāo)準(zhǔn)的語音引擎 上。該協(xié)議已經(jīng)被語音通信領(lǐng)域的主流供應(yīng)商所采用。MRCP不是一個獨立的 協(xié)議，必須依靠會話管理協(xié)議在客戶端和服務(wù)器之間建立媒體資源控制協(xié)議 MRCP控制會話。為了交互方便，MRCP選擇會話發(fā)起協(xié)議(Session Initiation Protocol, SIP)作為基本的會話管理協(xié)議，通過在客戶端和服務(wù)器之間的SIP 消息交互，協(xié)商出MRCP消息傳輸所需要的連接信息，其中，MRCP會話參 數(shù)用SIP消息體部分的會話描述協(xié)議(Session Description Protocol, SDP )描述。 服務(wù)器和客戶端之間，可以是有線網(wǎng)絡(luò)，也可以是無線網(wǎng)絡(luò)。但在現(xiàn)有技術(shù)中，利用無線網(wǎng)絡(luò)對數(shù)據(jù)進行傳輸時，對基于MRCP的消 息進行原樣傳輸，而由于無線網(wǎng)絡(luò)穩(wěn)定性差，消息傳輸時延較大，而如果傳輸 的數(shù)據(jù)量過多，將會降低網(wǎng)絡(luò)的利用率。發(fā)明內(nèi)容本發(fā)明實施例要解決的技術(shù)問題是提供一種消息傳輸方法及消息壓縮協(xié) 商請求及處理裝置，能夠降低基于MRCP的消息傳輸帶寬，提高網(wǎng)絡(luò)的利用 率。為解決上述技術(shù)問題，本發(fā)明實施例的目的是通過以下技術(shù)方案實現(xiàn)的本發(fā)明實施例提供了一種消息傳輸方法，包括服務(wù)器接收客戶端發(fā)送的會話描述協(xié)商請求，當(dāng)所述請求中媒體資源控制 協(xié)議MRCP所在的媒體行中添加了支持信令壓縮功能標(biāo)識，判斷得到服務(wù)器 支持信令壓縮功能，則在對客戶端會話描述協(xié)議協(xié)商請求的回應(yīng)中，設(shè)置支持 信令壓縮功能的標(biāo)識；客戶端接收回應(yīng)，并在回應(yīng)中查找到支持信令壓縮功能的標(biāo)識后，對傳 輸連接上的基于媒體資源控制協(xié)議的消息進行壓縮后傳輸。本發(fā)明實施例還提供一種消息壓縮協(xié)商請求處理裝置，該裝置包括數(shù)據(jù) 接收單元，數(shù)據(jù)解析單元，數(shù)據(jù)發(fā)送單元；數(shù)據(jù)接收單元，用于接收客戶端發(fā)起的會話描述協(xié)議協(xié)商請求，并將其發(fā) 送至數(shù)據(jù)解析單元；數(shù)據(jù)解析單元，用于在判斷得到所接收的協(xié)商請求中添加支持信令壓縮的 標(biāo)識后，判斷所述消息壓縮協(xié)商請求處理裝置是否支持信令壓縮功能，并根據(jù) 判斷結(jié)果決定是否在請求的回應(yīng)中設(shè)置支持信令壓縮的標(biāo)識，并將該回應(yīng)發(fā)送 至數(shù)據(jù)發(fā)送單元；數(shù)據(jù)發(fā)送單元，用于將所接收的請求回應(yīng)發(fā)送至客戶端。本發(fā)明實施例還提供一種消息壓縮協(xié)商請求裝置，該裝置包括協(xié)商請求 發(fā)送單元、數(shù)據(jù)接收單元、數(shù)據(jù)解析單元；協(xié)商請求發(fā)送單元，用于發(fā)起會話描述協(xié)議協(xié)商請求，并在會話描述協(xié)議 協(xié)商請求中MRCP所在的媒體行添加支持信令壓縮功能的標(biāo)識，將該請求發(fā) 送至服務(wù)器；數(shù)據(jù)接收單元，用于接收服務(wù)器端對協(xié)商請求的回應(yīng)，并將該回應(yīng)發(fā)送至 數(shù)據(jù)解析單元；數(shù)據(jù)解析單元，用于當(dāng)判斷得到接收的服務(wù)器端的回應(yīng)中，設(shè)置有支持信 令壓縮功能的標(biāo)識時，對基于MRCP的消息壓縮后傳輸，當(dāng)判斷得到服務(wù)器 端的回應(yīng)中，設(shè)置有不支持信令壓縮功能的標(biāo)識，或者判斷得到服務(wù)器端的回應(yīng)中沒有設(shè)置信令壓縮標(biāo)識時，對基于MRCP的消息原樣傳輸。以上技術(shù)方案可以看出，與現(xiàn)有技術(shù)對基于J 某體控制協(xié)議的消息進行原樣 傳輸相比，本發(fā)明實施例所提供的基于MRCP的消息傳輸?shù)姆椒ㄖ?，服?wù)器 端從客戶端發(fā)送的會話描述協(xié)議協(xié)商請求判斷出客戶端支持信令壓縮功能，在 服務(wù)器端同樣支持信令壓縮功能的情況下，在對客戶端的回應(yīng)中添加支持信令 壓縮功能的標(biāo)識，以支持協(xié)商基于MRCP的消息采取壓縮方式進行傳輸，從 而決定是降低々某體資源控制協(xié)議消息傳輸帶寬，使得當(dāng)客戶端傳輸?shù)臄?shù)據(jù)量過 多時，通過客戶端與服務(wù)器端的協(xié)商，對所要傳輸?shù)幕贛RCP的消息進行 壓縮后傳輸，進而降低^(某體資源控制協(xié)議消息傳輸占用的帶寬，提高網(wǎng)絡(luò)的利 用率。


圖1為本發(fā)明實施例中的方法流程圖； 圖2為本發(fā)明實施例中消息壓縮協(xié)商請求處理裝置結(jié)構(gòu)圖； 圖3為本發(fā)明實施例中消息壓縮協(xié)商請求裝置的結(jié)構(gòu)圖。
具體實施方式
為使本發(fā)明實施例的目的、技術(shù)方案及優(yōu)點更清楚，以下結(jié)合具體實施例 并參照附圖對本發(fā)明作詳細(xì)的闡述。參見圖1，本發(fā)明實施例所提供的一種消息傳輸方法，具體流程包括步驟101:服務(wù)器端接收客戶端發(fā)送的會話描述協(xié)議協(xié)商請求SDP offer, 并判斷該請求中MRCP所在的媒體行是否添加支持信令壓縮功能的標(biāo)識，如 果是，則進入步驟102,如果否，則進入步驟103;其中，客戶端是否支持信令壓縮功能，由客戶端使用設(shè)備的操作人員根據(jù) 實際情況決定，例如，當(dāng)操作人員認(rèn)為傳輸?shù)南⒘啃?，不會占用多少帶寬?則他可以決定客戶端不支持信令壓縮功能；其中，所述的客戶端發(fā)送的會話描述協(xié)議協(xié)商請求中支持信令壓縮功能的 標(biāo)識可以是屬性值為true的信令壓縮標(biāo)識，其中，所述的信令壓縮標(biāo)識及屬性可以是a = sigcomp屬性；其不支持信令壓縮功能的標(biāo)識可以是屬性值為false 的信令壓縮標(biāo)識，其中，所述的信令壓縮標(biāo)識及屬性可以是a = sigcomp屬性， 或者，通過客戶端發(fā)送的會話描述協(xié)議請求中不添加信令壓縮標(biāo)識以表示客戶 端不支持信令壓縮功能；其中，通常在無線網(wǎng)絡(luò)上傳輸基于媒體控制協(xié)議的消息時，無線網(wǎng)絡(luò)帶寬 不大，要求傳輸?shù)南⒈M量小，以節(jié)約帶寬；步驟102:服務(wù)器判斷服務(wù)器端是否支持信令壓縮功能，如果是，則進入 步驟104，如果否，則進入步驟103;其中，服務(wù)器不支持信令壓縮功能是由服務(wù)器端的策略決定的，例如，當(dāng) 服務(wù)器不能將大量的時間用在解壓消息上面，在此情況下，服務(wù)器端就可以不 支持信令壓縮功能；步驟103:服務(wù)器端在對客戶端的會話描述協(xié)議協(xié)商請求的回應(yīng)中，在 MRCP所在的媒體行添加表示服務(wù)器端不支持信令壓縮的標(biāo)識；或者在回應(yīng)中 不添加信令壓縮標(biāo)識，直4妄將回應(yīng)發(fā)送至客戶端，并進入步驟106;其中，所述的不支持信令壓縮功能的標(biāo)識可以是屬性值為false的信令壓 縮標(biāo)識，其中，所述的信令壓縮標(biāo)識及屬性可以是a = sigcomp屬性；步驟104:服務(wù)器端在對客戶端的會話描述協(xié)議協(xié)商請求的回應(yīng)中，MRCP 所在的J(某體行設(shè)置表示支持信令壓縮功能的標(biāo)識；其中，服務(wù)器端在對客戶端的會話描述協(xié)議協(xié)商請求的回應(yīng)中MRCP所 在的媒體行設(shè)置表示支持信令壓縮功能的標(biāo)識，可以為屬性值為true的信令壓 縮標(biāo)識，該信令標(biāo)識及屬性可以是a = sigcomp屬性；步驟105:傳輸連接上的基于MRCP消息通過壓縮后進行傳輸，結(jié)束程序；步驟106:傳輸連接上的基于MRCP的消息不進行壓縮，按原樣傳輸。從本實施例中可以看出，與現(xiàn)有技術(shù)對基于媒體控制協(xié)議的消息進行原樣 傳輸相比，本發(fā)明實施例中所提供的基于MRCP的消息傳輸?shù)姆椒ㄖ?，服?wù) 器端從客戶端發(fā)送的會話描述協(xié)議協(xié)商請求判斷出客戶端支持信令壓縮功能，在服務(wù)器端同樣支持信令壓縮功能的情況下，在對客戶端的回應(yīng)中添加支持信令壓縮功能的標(biāo)識，以支持協(xié)商基于MRCP的消息是否采取壓縮方式進行傳 輸，從而決定是否降低媒體資源控制協(xié)議消息傳輸帶寬，使得當(dāng)客戶端傳輸?shù)?數(shù)據(jù)量過多時，通過客戶端與服務(wù)器端的協(xié)商，對所要傳輸?shù)幕贛RCP的 消息進行壓縮后傳輸，進而降低^ 某體資源控制協(xié)議消息傳輸帶寬，提高網(wǎng)絡(luò)的 利用率。本發(fā)明實施例還提供了一種消息壓縮協(xié)商請求處理裝置，該裝置包括數(shù) 據(jù)接收單元，數(shù)據(jù)解析單元，數(shù)據(jù)發(fā)送單元；其中，數(shù)據(jù)接收單元201 ，用于接收有客戶端發(fā)起的會話描述協(xié)議協(xié)商請 求SDP Offer,并將其發(fā)送至數(shù)據(jù)解析單元；數(shù)據(jù)解析單元202,用于判斷所接收的協(xié)商請求中，是否添加支持信令壓 縮的標(biāo)識，判斷所述消息壓縮協(xié)商請求處理裝置是否支持信令壓縮功能，并根 據(jù)判斷結(jié)果決定在是否在請求的回應(yīng)中設(shè)置支持信令壓縮的標(biāo)識，并將該回應(yīng) 發(fā)送至數(shù)據(jù)發(fā)送單元；其中，數(shù)據(jù)解析單元包括判斷單元2021，回應(yīng)生成單元2022;其中，判斷單元2021，用于在判斷得到所接收的協(xié)商請求中添加了支持 信令壓縮功能的標(biāo)識，判斷得到本消息壓縮協(xié)商請求處理裝置支持信令壓縮功 能時，將該壓縮協(xié)商成功結(jié)果發(fā)送至回應(yīng)生成單元；當(dāng)判斷得到該協(xié)商請求中 添加了支持信令壓縮功能的標(biāo)識，判斷得到本消息壓縮協(xié)商請求處理裝置不支 持信令壓縮功能或者判斷得到所接收的協(xié)商請求中未添加支持信令壓縮的標(biāo) 識，將該壓縮協(xié)商失敗結(jié)果發(fā)送至回應(yīng)生成單元；其中，當(dāng)判斷得到消息壓縮協(xié)商請求處理裝置與客戶端均支持信令壓縮功 能，則協(xié)商成功；當(dāng)判斷得到消息壓縮裝置與客戶端中任一端不支持信令壓縮 功能，則協(xié)商失??；回應(yīng)生成單元2022，用于當(dāng)壓縮協(xié)商成功，在對該客戶端的請求回應(yīng)中 設(shè)置支持信令壓縮功能的標(biāo)識，并將其發(fā)送至數(shù)據(jù)發(fā)送單元；當(dāng)壓縮協(xié)商失敗， 在對客戶端的請求回應(yīng)中設(shè)置不支持信令壓縮功能的標(biāo)識，或者在回應(yīng)中不添加信令壓縮標(biāo)識，將回應(yīng)發(fā)送至數(shù)據(jù)發(fā)送單元；其中，所述的支持信令壓縮功能的標(biāo)識可以設(shè)置于MRCP所在的媒體行中；其中，本消息壓縮協(xié)商請求處理裝置是否支持信令壓縮裝置是由該裝置的 服務(wù)策略決定；其中，所述的支持信令壓縮功能的標(biāo)識可以是屬性值為true的信令壓縮標(biāo) 識，其中所述的信令壓縮標(biāo)識及屬性可以是a = sigcomp屬性；其中，所述的不支持信令壓縮功能的標(biāo)識可以是屬性值為false的信令壓 縮標(biāo)識，其中所述的信令壓縮標(biāo)識及屬性可以是a = sigcomp屬性；數(shù)據(jù)發(fā)送單元203,用于將所接收的請求回應(yīng)發(fā)送至客戶端。本發(fā)明還提供了一種消息壓縮協(xié)商請求裝置，該裝置包括協(xié)商請求發(fā)送 單元、數(shù)據(jù)接收單元、數(shù)據(jù)解析單元；其中，協(xié)商請求發(fā)送單元301,用于在會話描述協(xié)議協(xié)商請求中MRCP 所在的媒體行添加支持信令壓縮功能的標(biāo)識，并將該請求發(fā)送至服務(wù)器；數(shù)據(jù)接收單元302，用于接收服務(wù)器端對協(xié)商請求的回應(yīng)，并將該回應(yīng)發(fā) 送至解析單元；數(shù)據(jù)解析單元303，用于當(dāng)判斷得到接收的服務(wù)器端的回應(yīng)中，設(shè)置有支 持信令壓縮功能的標(biāo)識時，對基于MRCP的消息壓縮后傳輸，當(dāng)判斷得到服 務(wù)器端的回應(yīng)中，設(shè)置有不支持信令壓縮功能的標(biāo)識，或者判斷得到服務(wù)器端 的回應(yīng)中沒有設(shè)置信令壓縮標(biāo)識時，對基于MRCP的消息原樣傳輸。其中，所述的支持信令壓縮功能的標(biāo)識可以是屬性值為true的信令壓縮標(biāo) 識，其中所述的信令壓縮標(biāo)識及屬性可以是a = sigcomp屬性；其中，所述的不支持信令壓縮功能的標(biāo)識可以是屬性值為false的信令壓 縮標(biāo)識，其中所述的信令壓縮標(biāo)識及屬性可以是a = sigcomp屬性。以上技術(shù)方案可以看出，與現(xiàn)有技術(shù)對基于媒體控制協(xié)議的消息進行原樣 傳輸相比，本發(fā)明實施例所提供的基于MRCP的消息傳輸?shù)姆椒ㄖ校?wù)器端從客戶端發(fā)送的會話描述協(xié)議協(xié)商請求判斷出客戶端支持信令壓縮功能，在 服務(wù)器端同樣支持信令壓縮功能的情況下，在對客戶端的回應(yīng)中添加支持信令壓縮功能的標(biāo)識，以支持協(xié)商基于MRCP的消息是否釆取壓縮方式進行傳輸， 從而決定是否降低々某體資源控制協(xié)議消息傳輸帶寬，使得當(dāng)客戶端傳輸?shù)臄?shù)據(jù) 量過多時，通過客戶端與服務(wù)器端的協(xié)商，對所要傳輸?shù)幕贛RCP的消息 進行壓縮后傳輸，進而降低J(某體資源控制協(xié)議消息傳輸占用的帶寬，提高網(wǎng)絡(luò) 的利用率。以上對本發(fā)明所提供的一種消息傳輸方法及消息壓縮協(xié)商請求及處理裝 置進行了詳細(xì)介紹，本文中應(yīng)用了具體個例對本發(fā)明的原理及實施方式進行了 闡述，以上實施例的說明只是用于幫助理解本發(fā)明的方法及其核心思想；同時， 對于本領(lǐng)域的一般技術(shù)人員，依據(jù)本發(fā)明的思想，在具體實施方式
及應(yīng)用范圍 上均會有改變之處，因此，本說明書內(nèi)容不應(yīng)理解為對本發(fā)明的限制。
權(quán)利要求
1. 一種消息傳輸方法，其特征在于，包括服務(wù)器接收客戶端發(fā)送的會話描述協(xié)商請求，當(dāng)所述請求中媒體資源控制協(xié)議MRCP所在的媒體行中添加了支持信令壓縮功能標(biāo)識，判斷得到服務(wù)器支持信令壓縮功能，則在對客戶端會話描述協(xié)議協(xié)商請求的回應(yīng)中，設(shè)置支持信令壓縮功能的標(biāo)識；客戶端接收回應(yīng)，并在回應(yīng)中查找到支持信令壓縮功能的標(biāo)識后，對傳輸連接上的基于媒體資源控制協(xié)議的消息進行壓縮后傳輸。
2、 根據(jù)權(quán)利要求1所述的消息傳輸方法，其特征在于，該方法進一步包括當(dāng)服務(wù)器接收客戶端發(fā)送的會話描述協(xié)議協(xié)商請求，而該請求中媒體資源 控制協(xié)議所在的媒體行未添加支持信令壓縮的標(biāo)識時，則在對該請求的回應(yīng)中 添加不支持信令壓縮功能的標(biāo)識，或?qū)⒉惶砑有帕顗嚎s標(biāo)識的回應(yīng)發(fā)送給客戶 端；客戶端接收到回應(yīng)后，在傳輸連接上基于MRCP的消息按原樣進行傳輸。
3、 根據(jù)權(quán)利要求1所述的消息傳輸方法，其特征在于，該方法進一步包括當(dāng)服務(wù)器判斷得到服務(wù)器不支持信令壓縮功能時，則在對客戶端發(fā)送的會 話描述協(xié)議協(xié)商請求的回應(yīng)中，添加不支持信令壓縮功能的標(biāo)識，或?qū)⒉惶砑?信令壓縮標(biāo)識的回應(yīng)發(fā)送給客戶端；客戶端接收到回應(yīng)后，在傳輸連接上的基于MRCP的消息按原樣進行傳輸。
4、 根據(jù)權(quán)利要求2所述的消息傳輸方法，其特征在于，該方法中 所述的支持信令壓縮的標(biāo)識為屬性值為true的信令壓縮標(biāo)識； 所述的不支持信令壓縮功能的標(biāo)識為屬性值為false的信令壓縮標(biāo)識。
5、 一種消息壓縮協(xié)商請求處理裝置，其特征在于，該裝置包括數(shù)據(jù)接收單元，數(shù)據(jù)解析單元，數(shù)據(jù)發(fā)送單元；數(shù)據(jù)接收單元，用于接收客戶端發(fā)起的會話描述協(xié)議協(xié)商請求，并將其發(fā) 送至數(shù)據(jù)解析單元；數(shù)據(jù)解析單元，用于在判斷得到所接收的協(xié)商請求中添加支持信令壓縮的 標(biāo)識后，判斷所述消息壓縮協(xié)商請求處理裝置是否支持信令壓縮功能，并根據(jù) 判斷結(jié)果決定是否在請求的回應(yīng)中設(shè)置支持信令壓縮的標(biāo)識，并將該回應(yīng)發(fā)送 至數(shù)據(jù)發(fā)送單元；數(shù)據(jù)發(fā)送單元，用于將所接收的請求回應(yīng)發(fā)送至客戶端。
6、 根據(jù)權(quán)利要求5所述的消息壓縮協(xié)商請求處理裝置，其特征在于，所 述的數(shù)據(jù)解析單元包括判斷單元，回應(yīng)生成單元；判斷單元，用于在判斷得到所接收的協(xié)商請求中添加了支持信令壓縮功能 的標(biāo)識，以及判斷得到本消息壓縮協(xié)商請求處理裝置支持信令壓縮功能時，將 該壓縮協(xié)商成功結(jié)果發(fā)送至回應(yīng)生成單元；當(dāng)判斷得到該協(xié)商請求中添加了支 持信令壓縮功能的標(biāo)識，而判斷得到本消息壓縮協(xié)商請求處理裝置不支持信令 壓縮功能或者判斷得到所接收的協(xié)商請求中未添加支持信令壓縮的標(biāo)識，將該 壓縮協(xié)商失敗結(jié)果發(fā)送至回應(yīng)生成單元；回應(yīng)生成單元，用于當(dāng)壓縮協(xié)商成功，在對該客戶端的請求回應(yīng)中設(shè)置支 持信令壓縮功能的標(biāo)識，并將其發(fā)送至數(shù)據(jù)發(fā)送單元；當(dāng)壓縮協(xié)商失敗，在對 客戶端的請求回應(yīng)中設(shè)置不支持信令壓縮功能的標(biāo)識，或者在回應(yīng)中不添加信 令壓縮標(biāo)識，將回應(yīng)發(fā)送至數(shù)據(jù)發(fā)送單元。
7、 根據(jù)權(quán)利要求6所述的消息壓縮協(xié)商請求處理裝置，其特征在于 所述的支持信令壓縮的標(biāo)識為屬性值為true的信令壓縮標(biāo)識； 所述的不支持信令壓縮功能的標(biāo)識為屬性值為false的信令壓縮標(biāo)識。
8、 一種消息壓縮協(xié)商請求裝置，其特征在于，該裝置包括協(xié)商請求發(fā) 送單元、數(shù)據(jù)接收單元、數(shù)據(jù)解析單元；協(xié)商請求發(fā)送單元，用于發(fā)起會話描述協(xié)議協(xié)商請求，并在會話描述協(xié)議協(xié)商請求中MRCP所在的媒體行添加支持信令壓縮功能的標(biāo)識，將該請求發(fā) 送至服務(wù)器；數(shù)據(jù)接收單元，用于接收服務(wù)器端對協(xié)商請求的回應(yīng)，并將該回應(yīng)發(fā)送至 數(shù)據(jù)解析單元；數(shù)據(jù)解析單元，用于當(dāng)判斷得到接收的服務(wù)器端的回應(yīng)中，設(shè)置有支持信 令壓縮功能的標(biāo)識時，對基于MRCP的消息壓縮后傳輸，當(dāng)判斷得到服務(wù)器 端的回應(yīng)中，設(shè)置有不支持信令壓縮功能的標(biāo)識，或者判斷得到服務(wù)器端的回 應(yīng)中沒有設(shè)置信令壓縮標(biāo)識時，對基于MRCP的消息原樣傳輸。
9、根據(jù)權(quán)利要求8所述的消息壓縮協(xié)商請求裝置，其特征在于所述的支持信令壓縮功能的標(biāo)識屬性值為true的信令壓縮標(biāo)識；所述的不支持信令壓縮功能的標(biāo)識屬性值為false的信令壓縮標(biāo)識。
全文摘要
本發(fā)明公開了一種消息傳輸方法及消息壓縮協(xié)商請求及處理裝置，通過對MRCP所在的媒體行進行擴展，以支持協(xié)商基于MRCP的消息傳輸是否采取壓縮的方式，從而決定是否降低MRCP消息傳輸所占的帶寬。利用本發(fā)明，能夠降低基于MRCP的消息傳輸帶寬，提高網(wǎng)絡(luò)的利用率。
文檔編號H04L29/06GK101232492SQ20071000292
公開日2008年7月30日 申請日期2007年1月26日 優(yōu)先權(quán)日2007年1月26日
發(fā)明者奇 王 申請人:華為技術(shù)有限公司