專利名稱：一種PoC業(yè)務(wù)處理方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)通信技術(shù)領(lǐng)域，更具體地說，涉及一種PoC業(yè)務(wù)處理方 法禾p系統(tǒng)。
背景技術(shù)：
無線一4走通(Push-to-Talk Over Cellular,簡稱"PoC，，)業(yè)務(wù)定義了 一種適 合移動設(shè)備的具有半雙工對講功能的移動數(shù)據(jù)業(yè)務(wù)，PoC采用半雙工通信方 式，可以進行"一對一"、"一對多"通話，而且具有一按即通、無需撥號等待等 特點，PoC改變了人們使用移動電話"一對一"的傳統(tǒng)通話方式，用戶能夠與任 何地方的多個用戶進行"一對多"的即時通話。這種通話方式解決了商務(wù)客戶的 需求，例如建筑施工隊、現(xiàn)場銷售隊伍、快遞人員和物流服務(wù)隊伍進行即時的 集群通信，還能進行語音短信、家庭會議等復(fù)雜業(yè)務(wù)。
PoC的一般過程是主叫先向服務(wù)器提出會話請求，服務(wù)器然后向單個用戶 或群組中的所有成員發(fā)送會話請求，服務(wù)器然后向單個用戶或群組中的所有成 員發(fā)送會話請求，其具體過程實現(xiàn)如下(1)發(fā)送端建立會話；(2 )發(fā)送端對 會話數(shù)據(jù)進行編碼；(3)對編碼后的數(shù)據(jù)進行封包，構(gòu)造數(shù)據(jù)包；(4)發(fā)送端 發(fā)送數(shù)據(jù)包到服務(wù)器，服務(wù)器接收數(shù)據(jù)包后轉(zhuǎn)發(fā)給接收端；(5)接收端對接收 到的數(shù)據(jù)包解碼，生成數(shù)據(jù)?，F(xiàn)有技術(shù)在編碼和解碼的過程中一般采用單線程 的處理方法，在語音通話過程中，構(gòu)造數(shù)據(jù)包多采用一個語音幀構(gòu)造一個數(shù)據(jù) 包，因此，現(xiàn)有技術(shù)的通話延遲時間長，并且通話質(zhì)量不高，通話時間長一直 是限制PoC業(yè)務(wù)發(fā)展的因素，在集群網(wǎng)絡(luò)上， 一鍵通(Push-To-Talk，筒稱 "PTT，，)業(yè)務(wù)的呼叫建立延遲凈皮控制在一秒鐘之內(nèi)，而目前的PoC在呼叫建 立環(huán)節(jié)上一般有3~10秒的延遲，在延遲問題上PoC與集群網(wǎng)絡(luò)上的PTT業(yè)務(wù) 還有4交大差距。除此之外，現(xiàn)有的PoC業(yè)務(wù)單一，〗又應(yīng)用于語音通話的PoC業(yè)務(wù)無法滿足客戶的需求。
因此，需要一種新的PoC業(yè)務(wù)處理方法及系統(tǒng)，能降低通話延遲，提高 通話效率。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種PoC業(yè)務(wù)處理系統(tǒng)，旨在解決現(xiàn)有技術(shù)的通話
延遲時間長、通話效率不高的問題。
本發(fā)明的目的還在于提供一種PoC業(yè)務(wù)處理方法，以更好地解決現(xiàn)有技術(shù)
中存在的上述問題。
為了實現(xiàn)發(fā)明目的，所述PoC業(yè)務(wù)處理系統(tǒng)，包括服務(wù)端和客戶端，所 述服務(wù)端包括用于對媒體進行判斷、分發(fā)和管理的媒體服務(wù)器，所述客戶端包 括用于將會話輸入轉(zhuǎn)換成編碼格式以及將接收到的數(shù)據(jù)包轉(zhuǎn)換成可以直接播 放的語音流格式的語音編解碼模塊，以及用于對需要發(fā)送的文件進行分包發(fā)送 以及對收到的文件包進行重組保存的文件處理模塊，所述語音編解碼才莫塊采用 多線程處理方法和編碼算法，將會話輸入轉(zhuǎn)換成編碼格式以及將收到的數(shù)據(jù)包 轉(zhuǎn)換成可以直接播放的語音流格式。
優(yōu)選地，所述編碼算法為AMR算法。
優(yōu)選地，所述文件處理模塊進一步用于對丟失的文件包進行重新發(fā)送；所 述媒體服務(wù)器進一步用于控制發(fā)言權(quán)，向文件發(fā)送者請求重新發(fā)送丟失的文 件，對丟失或中途加入的用戶進行文件包重傳。
為了更好的實現(xiàn)發(fā)明目的，所述PoC業(yè)務(wù)處理方法，基于服務(wù)端和至少 兩個客戶端，所述至少兩個客戶端包括客戶發(fā)送端和客戶接收端，所述方法包 括以下步驟
A. 客戶發(fā)送端建立會話，采集語音；
B. 客戶發(fā)送端通過多線程處理方法和編碼算法對語音數(shù)據(jù)進行編碼；
C. 客戶發(fā)送端對編碼后的數(shù)據(jù)進行封包，構(gòu)造數(shù)據(jù)包；
D. 客戶發(fā)送端發(fā)送數(shù)據(jù)包到服務(wù)端，服務(wù)端接收數(shù)據(jù)包并分發(fā)給客戶接E.客戶接收端接收數(shù)據(jù)包，通過多線程處理方法和編碼算法對數(shù)據(jù)包進行 解碼，生成語音。
優(yōu)選地，所述步驟B進一步包括:客戶發(fā)送端通過多線程處理方法和AMR 編碼算法對數(shù)據(jù)進行編碼。
優(yōu)選地，所述步驟C進一步包括對編碼后的語音數(shù)據(jù)封包時采用至少 兩個幀構(gòu)造一個數(shù)據(jù)包。
優(yōu)選地，所述步驟D進一步包括
Dl .客戶發(fā)送端采用"重發(fā)控制"方式將數(shù)據(jù)包發(fā)送給服務(wù)端； D2.服務(wù)端采用"重發(fā)控制"方式將數(shù)據(jù)包分發(fā)給客戶接收端。 進一步優(yōu)選地，所述步驟D1中的"重發(fā)控制"方式為 Dl 1 .客戶發(fā)送端發(fā)送數(shù)據(jù)包給服務(wù)端，全部的數(shù)據(jù)包發(fā)送完畢后發(fā)送"釋 放發(fā)言"請求到服務(wù)端；
D12.服務(wù)端收到數(shù)據(jù)包并保存，收到"釋放發(fā)言"請求時檢查文件是否完
整；
D13.若文件完整，服務(wù)端發(fā)送"擴充TBCP消息"通知給客戶發(fā)送端結(jié)束 會話；
D14.若文件不完整，服務(wù)端發(fā)送"擴充TBCP消息"給客戶發(fā)送端，請求 發(fā)送丟失的數(shù)據(jù)，重復(fù)Dll。
進一步優(yōu)選地，所述步驟D1中的"重發(fā)控制"方式為
D21.服務(wù)端分發(fā)數(shù)據(jù)包給客戶接收端，發(fā)送完畢后向客戶接收端發(fā)送"會 話空閑"消息；
D22.接收端收到數(shù)據(jù)包后解碼恢復(fù)文件，收到"會話空閑"消息時檢查文件 是否完整；
D23.若文件完整，接收端結(jié)束會話；
D24.若文件不完整，接收端發(fā)送"擴充TBCP消息"給服務(wù)端，請求發(fā)送丟 失的數(shù)據(jù)，重復(fù)D21。
優(yōu)選地，所述步驟E進一步包括客戶接收端收到語音數(shù)據(jù)包后，參考 該數(shù)據(jù)包的時間戳和包序號將其插入緩沖區(qū)中或丟棄，采用更新播放隊列的方式生成i吾音。
本發(fā)明通過多線程處理方法和AMR算法對語音數(shù)據(jù)進行編解碼，由于多 線程處理方法能實現(xiàn)在采集語音數(shù)據(jù)的同時進行編碼，有效的降低了通話延 遲，提高了通話效率，而AMR算法在保證通話效果的勤出上有著較大的壓縮 率，也縮短了通話延遲，并且AMR算法在編碼前會對躁聲進4亍有效的抑制， 能提高通話質(zhì)量。另夕卜，本發(fā)明采用"重發(fā)控制，，方式對數(shù)據(jù)包進行發(fā)送和接收， 能保證文件傳輸?shù)耐暾浴?br>

,
圖1是本發(fā)明中Poc業(yè)務(wù)處理系的系統(tǒng)結(jié)構(gòu)圖2是本發(fā)明的一個實施例中PoC業(yè)務(wù)處理系統(tǒng)服務(wù)端的內(nèi)部結(jié)構(gòu)圖； 圖3是本發(fā)明的一個實施例中PoC業(yè)務(wù)處理系統(tǒng)客戶端的內(nèi)部結(jié)構(gòu)圖； 圖4是本發(fā)明PoC業(yè)務(wù)處理方法的流程圖； 圖5是本發(fā)明的一個實施例中PoC業(yè)務(wù)處理的方法流程圖； 圖6是本發(fā)明的一個實施例中客戶接收端更新播放隊列的方法流程圖； 圖7是本發(fā)明的一個實施例中PoC業(yè)務(wù)處理/A^戶發(fā)送端到服務(wù)端的方 法流程圖8是 本發(fā)明的一個實施例中PoC業(yè)務(wù)處理從服務(wù)端到客戶接收端的方 法流程圖。
具體實施例方式
為了使本發(fā)明的目的、技術(shù)方案及優(yōu)點更加清楚明白，以下結(jié)合附圖及實 施例，對本發(fā)明進行進一步詳細說明。應(yīng)當理解，此處所描述的具體實施例l又 僅用以解釋本發(fā)明，并不用于限定本發(fā)明。
本發(fā)明通過在編碼和解碼過程中采用多線程處理方法和AMR算法，降低 了 PoC業(yè)務(wù)處理中語音通話的延遲，有效的提高了通話效率。
圖1示出了本發(fā)明中PoC業(yè)務(wù)處理的系統(tǒng)結(jié)構(gòu)圖，該系統(tǒng)包括月良務(wù)器100 和多個客戶端，如客戶端200、客戶端300......客戶端N。應(yīng)當說明的是，本發(fā)明所有圖示中各設(shè)備之間的連接關(guān)系是為了清楚闡釋 其信息交互及控制過程的需要，因此應(yīng)當視為邏輯上的連接關(guān)系，而不應(yīng)僅限 于物理連接。
月良務(wù)端100與多個客戶端(客戶端200、客戶端300......客戶端N)相連，
用于對數(shù)據(jù)進行接收保存并分發(fā)給不同的客戶端。各客戶端(客戶端200、客 戶端300......客戶端N)可為終端通信設(shè)備，例如智能手機平臺。
各客戶端與服務(wù)端100相連，其與服務(wù)端IOO之間的會話建立和呼叫控制 采用會話發(fā)起協(xié)議(Session Initiation Protocol,簡稱"SIP")協(xié)議和實時傳輸 協(xié)-漢/實時傳輸控制協(xié)議(Real Time Transport Protocol/Real Time Transport Control Protocol,簡稱"RTP/RTCP")協(xié)議。
圖2示出了本發(fā)明的一個實施例中PoC業(yè)務(wù)處理系統(tǒng)服務(wù)端100的內(nèi)部 結(jié)構(gòu)圖，該服務(wù)端100的內(nèi)部結(jié)構(gòu)并不是本發(fā)明的服務(wù)端IOO最簡結(jié)構(gòu)，另外 也可在其上進行擴展。該服務(wù)端100的內(nèi)部結(jié)構(gòu)是在PoC業(yè)務(wù)處理中的一個 典型結(jié)構(gòu)。在本發(fā)明的一個實施例中，服務(wù)端100包括會議工廠101、媒體服 務(wù)器102、呈現(xiàn)服務(wù)器103和SIP服務(wù)器104,其中，
會議工廠101,與SIP服務(wù)器104相連，用于響應(yīng)客戶端會話請求，生成 會話請求給一個或多個被邀請者，建立會話，接收客戶端退出、重新加入會話
等操作。
媒體服務(wù)器102，用于對媒體進行判斷、分發(fā)和管理，還用于控制發(fā)言權(quán)， 向文件發(fā)送者請求重新發(fā)送丟失的文件，對丟失或中途加入的用戶進行文件包 重傳。
呈現(xiàn)服務(wù)器103,與SIP服務(wù)器104相連，用于管理PoC用戶的狀態(tài)，接 收用戶狀態(tài)更新。
SIP服務(wù)器104,與會議工廠101和呈現(xiàn)服務(wù)器103相連，用于接受客戶 端、會議工廠101和呈現(xiàn)服務(wù)器103的注冊請求和管理注冊信息，以及充當 SIP地址路由功能，把對SIP地址的請求轉(zhuǎn)發(fā)到對應(yīng)的機器。
圖3示出了本發(fā)明的一個實施例中PoC業(yè)務(wù)處理系統(tǒng)客戶端200的內(nèi)部 結(jié)構(gòu)圖，該客戶端200的內(nèi)部結(jié)構(gòu)并不是本發(fā)明的客戶端最簡結(jié)構(gòu)，另外也可 在其上進行擴展。該客戶端200的內(nèi)部結(jié)構(gòu)是在PoC業(yè)務(wù)處理中的一個典型結(jié)構(gòu)。在本發(fā)明的一個實施例中，客戶端200包括界面201、控制模塊202、 SIP協(xié)議處理模塊203、語音采集/播放模塊204、語音編解碼模塊205、發(fā)言 控制模塊206、文件處理沖莫塊207、流處理模塊208和網(wǎng)絡(luò)209。其中，
界面201，與控制模塊202相連，用于完成用戶配置、群組管理和用戶交 互等過程，以及負責(zé)^l巴用戶動作傳遞給控制模塊202。
控制模塊202,與界面201、 SIP協(xié)議處理模塊203、語音采集/播放模塊 204、發(fā)言控制模塊206、文件處理模塊207相連，用于把處理結(jié)果或接收的 數(shù)據(jù)信息反饋到界面201;用于把分解后的注冊請求、會話(包括文件會話) 請求、會話退出等消息傳遞給SIP協(xié)議處理模塊203處理；用于根據(jù)語音會話 建立結(jié)果控制是否開啟語音采集/播放模塊204;用于把用戶的發(fā)言請求等傳遞 給發(fā)言控制模塊206;以及文件會話建立后，驅(qū)動文件處理模塊207開始發(fā)送 或接收文件。
SIP協(xié)議處理模塊203，與控制模塊202和網(wǎng)絡(luò)209相連，用于把用戶相 應(yīng)操作轉(zhuǎn)化為SIP指令，發(fā)送到SIP服務(wù)器104,并解釋收到的SIP指令，完 成用戶的注冊、會話建立過程；用于把服務(wù)端IOO的最終處理結(jié)果返回給控制 模塊202。
語音采集/播放模塊204,與控制模塊202、語音編解碼模塊205和發(fā)言控 制模塊206相連，用于采集用戶的發(fā)言和播放語音，并把采集到的數(shù)據(jù)傳遞到 語音編解碼一莫塊205進行編碼。
語音編解碼模塊205,與語音采集/播放模塊204、發(fā)言控制模塊206和流 處理模塊208相連，用于采用多線程處理方法和編碼算法將會話輸入轉(zhuǎn)換成編 碼格式以及將收到的數(shù)據(jù)包轉(zhuǎn)換成可以直接播;改的語音流格式；用于將編碼后 的語音數(shù)據(jù)傳遞給流處理模塊208進行封裝。
發(fā)言控制模塊206，與控制模塊202、語音采集/播放模塊204、語音編解 碼模塊205、文件處理模塊207和流處理模塊208相連，用于把從服務(wù)端IOO 收到的控制信息傳遞給控制模塊202，控制語音采集/播放模塊204采集的數(shù)據(jù) 是否有效，是否允許語音采集/播放模塊204播放語音數(shù)據(jù)；控制語音編解碼 模塊205進行編碼；控制文件處理模塊207對文件數(shù)據(jù)包發(fā)送以及文件數(shù)據(jù)包的重發(fā)處理和重發(fā)請求等；控制流處理^t塊208對上層傳遞的或接收到的語音 數(shù)據(jù)是否做有效處理；用于把自己的控制信息通過流處理模塊208對其進行封 裝，發(fā)送服務(wù)端100;用于對擴充消息的處理以及完成發(fā)言狀態(tài)的變換。
文件處理模塊207，與控制模塊202、發(fā)言控制模塊206和流處理模塊208 相連，用于對需要發(fā)送的文件進行分包發(fā)送以及對收到的文件包進行重組保 存。此外，文件處理模塊207還用于對丟失的文件包進行重新發(fā)送。
流處理模塊208,與語音編解碼模塊205、發(fā)言控制模塊206、文件處理 模塊207和網(wǎng)絡(luò)209相連，用于將語音編解碼模塊205傳遞過來的數(shù)據(jù)進行封 裝，構(gòu)造數(shù)據(jù)包并通過網(wǎng)絡(luò)209發(fā)送至服務(wù)端100;用于將服務(wù)端100收到的 控制信息傳遞給發(fā)言控制模塊206;用于將文件處理模塊207傳遞過來的文件 數(shù)據(jù)進行協(xié)議封裝，構(gòu)造文件數(shù)據(jù)包并通過網(wǎng)絡(luò)209發(fā)送至服務(wù)端100。
網(wǎng)絡(luò)209，與SIP協(xié)議處理才莫塊203和流處理沖莫塊208相連，用于完成數(shù) 據(jù)在網(wǎng)絡(luò)中的傳輸。
其他客戶端300、客戶端400...客戶端N與客戶端200的內(nèi)部結(jié)構(gòu)相同， 在次不做多余描述。
圖4示出了本發(fā)明PoC業(yè)務(wù)處理方法的流程圖，該方法基于圖1所示的 系統(tǒng)結(jié)構(gòu)，其中不同的用戶登陸到客戶端200、客戶端300...客戶端N中，該 方法包括以下步驟
在步驟S401中，客戶發(fā)送端建立會話，采集語音；
在步驟S401中，客戶發(fā)送端通過多線程處理方法和編碼算法對語音數(shù)據(jù) 進行編碼；
在步驟S403中，客戶發(fā)送端對編碼后的數(shù)據(jù)進行封包，構(gòu)造數(shù)據(jù)包；
在步驟S404中，客戶發(fā)送端發(fā)送數(shù)據(jù)包到服務(wù)端，服務(wù)端接收數(shù)據(jù)包并 分發(fā)給客戶接收端；
在步驟S405中，客戶接收端通過多線程處理方法和編碼算法對數(shù)據(jù)包進 行解碼，生成語音。
圖5示出了本發(fā)明的一個實施例中PoC業(yè)務(wù)處理的方法流程圖，該方法 基于圖1、圖2和圖3所示的系統(tǒng)結(jié)構(gòu)，當用戶請求發(fā)言時，其登陸的客戶端稱之為客戶發(fā)送端(以下簡稱發(fā)送端)，而被邀請的用戶登陸的客戶端稱之為
客戶接收端(以下簡稱接收端)，具體包括以下步驟
在步驟S501中，發(fā)送端建立會話，采集數(shù)據(jù)。在一實施例中，其具體過 程為發(fā)送端通過SIP協(xié)議處理模塊203建立會話，由控制模塊202通知語音 采集/播放模塊204開始采集語音。
在步驟S502中，發(fā)送端通過多線程處理方法和編碼算法對語音數(shù)據(jù)進行 編碼。在一個實施例中，該步驟具體實現(xiàn)過程為當發(fā)送端的語音采集/播力文 模塊204每采集一個語音幀數(shù)據(jù)，控制模塊202就通知語音編解碼模塊205 對采集到的語音幀數(shù)據(jù)使用多線程處理方法和自適應(yīng)網(wǎng)格(Adaptive Mesh Refinement,簡稱"AMR")算法進行編碼。使用多線程處理方法，可以實現(xiàn) 語音采集/播放模塊204在采集語音的同時，語音編解碼模塊205就能對語音 進行編碼，縮短了通話延遲，例如，每編碼一個20毫秒的語音幀數(shù)據(jù)大約需 要11毫秒，則采集k幀語音需要的時間為20*k+ll毫秒，遠小與單線程處理 的(20+11 ) *化毫秒。
使用AMR算法對語音幀數(shù)據(jù)進行編碼，在一實施例中，其具體過程包括 (1)在對語音幀數(shù)據(jù)編碼前對躁聲做有效的抑制；(2)使用5.15kbit/s編碼 速率對語音幀數(shù)據(jù)進行壓縮處理；(3 )將靜音數(shù)據(jù)進行零字節(jié)處理。
在步驟S503中，對編碼后的語音數(shù)據(jù)進行封包，構(gòu)造語音數(shù)據(jù)包。在一 實施例中，其具體實現(xiàn)過程為流處理^^莫塊209將語音編解碼^^莫塊205編碼后 傳遞過來的語音數(shù)據(jù)進行封裝，構(gòu)造語音數(shù)據(jù)包，如逐層封裝成實時傳輸協(xié)議 (Real Time Transport Protocol,簡稱"RTP")數(shù)據(jù)包、用戶數(shù)據(jù)報協(xié)議(User Datagram Protocol,簡稱"UDP")數(shù)據(jù)包和網(wǎng)際協(xié)議(Internet Protocol,簡 稱"IP")數(shù)據(jù)包。在一實施例中，對編碼后的語音數(shù)據(jù)封包時采用至少兩個 幀構(gòu)造一個數(shù)據(jù)包，更好的，在延時許可范圍內(nèi)采用3個編碼后的語音幀構(gòu)造 一個數(shù)據(jù)包。
在步驟S504中，發(fā)送端發(fā)送數(shù)據(jù)包到服務(wù)端，服務(wù)端接收數(shù)據(jù)包并分發(fā) 給接收端。在一實施例中，發(fā)送端通過網(wǎng)絡(luò)209發(fā)送至服務(wù)端100,服務(wù)端100 接收語音數(shù)據(jù)包后分發(fā)給各接收端。在步驟S505中，接收端收到語音數(shù)據(jù)包后，參考該數(shù)據(jù)包的時間戳和包 序號將其插入緩沖區(qū)中或丟棄，采用更新播放隊列的方式生成語音。在一個實
施例中，流處理模塊208每收到一個RTP包，就參考該RTP包的時間戳和包 序號將其插入緩沖區(qū)中或丟棄，在語音編解碼模塊205對RTP包解碼后，控 制模塊202通知語音采集/播放模塊204更新播放隊列。
圖6示出了本發(fā)明的一個實施例中客戶接收端更新播放隊列的方法流程 圖。在一實施例中，該方法具體實現(xiàn)過程如下
(1) 當初始播放語音時，掃描緩沖區(qū)，當緩沖區(qū)中的語音數(shù)據(jù)滿足以下 3個條件之一后，則取語音數(shù)據(jù)包，并對語音數(shù)據(jù)包進行解碼，加入播放隊列， 當播放隊列中有數(shù)據(jù)時，語音采集/播放模塊204依次播放隊列中的語音數(shù)據(jù) a)緩沖區(qū)中的RTP包的個數(shù)大于或等于3個；b )緩沖區(qū)中有兩個順序的RTP 包，其時間戳的間隔大于一個語音幀時間(即兩個RTP包中間有未被發(fā)送的 靜音數(shù)據(jù))；c)緩沖區(qū)中RTP包的個數(shù)小于3個，但第一個RTP包已等待足 夠長的時間；
(2) 接收端每收到一個RTP包，或者上次掃描緩沖區(qū)11毫秒后，重新 掃描緩沖區(qū)；
(3 )根據(jù)上一次加入播;改隊列的RTP包的序號，判斷緩沖區(qū)中是否有下 一個RTP包；
(4) 若緩沖區(qū)中有下一個期待的RTP包，判斷該RTP包和上一個RTP 時間戳間隔是否大于一個語音幀時間，若是，則恢復(fù)未被發(fā)送的靜音數(shù)據(jù)并插 入播放隊列中；若不是，則將該期待的RTP包直接解碼，加入播放隊列。
(5) 若緩沖區(qū)中沒有下一個期待的RTP包，判斷播放隊列是否為空，即 是否還有待播放的語音數(shù)據(jù)，若有，則等待ll毫秒，重復(fù)步驟(2);若沒有， 則將緩沖區(qū)中最舊的RTP包解碼，然后將其和20毫秒的靜音數(shù)據(jù)插入播放隊 列中；
(6 )如果播放過程未被終止，重復(fù)(2 ) (5 )。
在步驟S506中，接收端對更新的數(shù)據(jù)進行解碼時采多線程處理方法和編 碼算法進行解碼。在一個實施例中，該步驟具體實現(xiàn)過程為流處理模塊208每收到一個語音數(shù)據(jù)包，控制模塊202就通知語音編解碼才莫塊205對語音數(shù)據(jù) 包進行解碼，將語音數(shù)據(jù)包轉(zhuǎn)換為可以直接播放的語音流格式，使用多線程處 理方法，可以實現(xiàn)語音采集/播放模塊204在播放語音的同時，語音編解碼模 塊205就能對語音數(shù)據(jù)包進行解碼，縮短了通話延遲，例如，每解碼2個語音 幀數(shù)據(jù)(即一個RTP包)花費時間約為6毫秒，則語音解碼造成的通話延遲 僅為6毫秒。在一示例中，使用AMR算法對語音數(shù)據(jù)包進行解碼，AMR算 法在解碼的過程中對失真的語音數(shù)據(jù)進行有效補償，能使噪聲最小、失真最低。 在PoC業(yè)務(wù)處理中，對于實時的語音數(shù)據(jù)會話，當會話過程中語音數(shù)據(jù) 丟失時， 一般不需要重新發(fā)送丟失的語音數(shù)據(jù)，但是，當客戶發(fā)送端發(fā)送的數(shù) 據(jù)為非實時數(shù)據(jù)時，例如文檔、圖片等，相對于語音數(shù)據(jù)，其完整性非常重要。
本發(fā)明的一個實施例通過對文件傳輸?shù)母倪M，采用"重發(fā)控制"方式通過發(fā)送 "講話段控制協(xié)議(Talk Brust Control Protocol,簡稱"TBCP")擴充消息" 實現(xiàn)文件數(shù)據(jù)的重發(fā)，從而保證了文件的完整性。
圖7示出了本發(fā)明的一個實施例中PoC業(yè)務(wù)處理從客戶發(fā)送端到J11務(wù)端 的方法流程圖。該方法基于圖1、圖2和圖3所示的系統(tǒng)結(jié)構(gòu)，當用戶請求發(fā) 送文件時，其登陸的客戶端稱之為客戶發(fā)送端(以下簡稱發(fā)送端)，而發(fā)送文 件的對象登陸的客戶端稱之為客戶接收端(以下簡稱接收端)，具體包括以下 步驟
在步驟S701中，發(fā)送端讀取文件數(shù)據(jù)、編碼、組裝文件數(shù)據(jù)包。在一實 施例中，其具體過程為(1 )由SIP協(xié)議處理模塊203通過SIP協(xié)i義建立文件 傳輸會話；(2 )由控制模塊202驅(qū)動文件處理模塊207對文件分成若干塊，并 為每塊數(shù)據(jù)添加序號；(3 )由流處理模塊208將相應(yīng)的文件塊依次組裝成文件 數(shù)據(jù)包(如RTP包)，并通過網(wǎng)絡(luò)209發(fā)送出去。
在步驟S702中，發(fā)送端發(fā)送文件數(shù)據(jù)包給服務(wù)端100，全部的數(shù)據(jù)包發(fā) 送完畢后發(fā)送"釋放發(fā)言"請求到服務(wù)端100。
在步驟S703中，服務(wù)端100收到數(shù)據(jù)包并保存，收到"釋》文發(fā)言"請求時 檢查文件是否完整。在一實施例中，其具體實現(xiàn)過程為(l)服務(wù)端收到文件 數(shù)據(jù)包后保存，若為小文件則緩存在內(nèi)存中，若為大文件則寫在^t盤上；(2)記錄已接收文件塊的序號；(3)服務(wù)端收到"釋放發(fā)言"請求時，由媒體服務(wù)器 102檢查文件是否完整。
在步驟S704中，若文件完整，服務(wù)端100發(fā)送"擴充TBCP消息"通知給 發(fā)送端。在一實施例中，其具體實現(xiàn)過程為若文件完整，由々某體服務(wù)器102 發(fā)送"擴充TBCP消息"通知給發(fā)送端。
在步驟S705中，接收端收到通知，結(jié)束會話。在一實施例中，其具體實 現(xiàn)過程為發(fā)言控制模塊206根據(jù)"擴充的TBCP消息"中相應(yīng)的標識位，判斷 是否已接收完畢，接收完畢則結(jié)束會話。
在步驟S706中，若文件不完整，服務(wù)端IOO發(fā)送"擴充TBCP消息"給客 戶發(fā)送端，請求發(fā)送丟失的數(shù)據(jù)，重復(fù)步驟S702。在一實施例中，其具體實 現(xiàn)過程為若文件不完整，由媒體服務(wù)器102發(fā)送"擴充TBCP消息"給發(fā)送端， 請求發(fā)送丟失的數(shù)據(jù)，，發(fā)言控制模塊206根據(jù)"擴充TBCP消息"中相應(yīng)的標 識文，來判斷未接收完畢時所缺少的文件序號，重復(fù)步驟S702。
圖8示出了本發(fā)明的一個實施例中PoC業(yè)務(wù)處理從服務(wù)端到客戶接收端 的方法流程圖。具體包括以下步驟
在步驟S801中，服務(wù)端IOO分發(fā)文件數(shù)據(jù)包給相應(yīng)的接收端，發(fā)送完畢 后向其發(fā)送"會話空閑"消息。在一實施例中，其具體實現(xiàn)過程為由媒體服務(wù) 器102分發(fā)文件數(shù)據(jù)包(如RTP包)給相應(yīng)的接收端，發(fā)送完畢后向接收端 發(fā)送"會話空閑"消息。
在步驟S802中，接收端收到文件數(shù)據(jù)包解碼恢復(fù)文件，收到"會話空閑" 消息時檢查文件。在一實施例中，其具體實現(xiàn)過程為(1)由控制模塊202 驅(qū)動文件處理模塊207根據(jù)收到的文件塊序號對文件進行恢復(fù)；(2 )記錄下已 接收文件的序號；(3 )收到"會話空閑"消息時文件處理模塊207根據(jù)已接收文 件塊的序號檢查文件是否完整。
在步驟S803中，若文件完整，接收端結(jié)束會話。
在步驟S804中，若文件不完整，接收端發(fā)送"擴充TBCP消息"給服務(wù)端 100，請求發(fā)送丟失的數(shù)據(jù)，重復(fù)步驟S801。在一實施例中，其具體實現(xiàn)過程 為若文件不完整，發(fā)言控制模塊206控制文件處理模塊207發(fā)送"控制TBCP消息"給服務(wù)端IOO,請求發(fā)送丟失的數(shù)據(jù)，重復(fù)步驟S801。
以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā) 明的精神和原則之內(nèi)所作的任何修改、等同替換和改進等，均應(yīng)包含在本發(fā)明 的j呆護范圍之內(nèi)。
權(quán)利要求
1、一種PoC業(yè)務(wù)處理系統(tǒng)，包括服務(wù)端和客戶端，所述服務(wù)端包括用于對媒體進行判斷、分發(fā)和管理的媒體服務(wù)器，所述客戶端包括用于將會話輸入轉(zhuǎn)換成編碼格式以及將接收到的數(shù)據(jù)包轉(zhuǎn)換成可以直接播放的語音流格式的語音編解碼模塊，以及用于對需要發(fā)送的文件進行分包發(fā)送以及對收到的文件包進行重組保存的文件處理模塊，其特征在于，所述語音編解碼模塊采用多線程處理方法和編碼算法，將會話輸入轉(zhuǎn)換成編碼格式，以及將收到的數(shù)據(jù)包轉(zhuǎn)換成可以直接播放的語音流格式。
2、 根據(jù)權(quán)利要求1所述的PoC業(yè)務(wù)處理系統(tǒng)，其特征在于，所述編碼算 法為AMR算法。
3、 根據(jù)權(quán)利要求1所述的PoC業(yè)務(wù)處理系統(tǒng)，其特征在于，所述文件處 理模塊進一步用于對丟失的文件包進行重新發(fā)送；所述々某體服務(wù)器進一步用于 控制發(fā)言權(quán)，向文件發(fā)送者請求重新發(fā)送丟失的文件，對丟失或中途加入的用 戶進行文件包重傳。
4、 一種PoC業(yè)務(wù)處理方法，所述方法基于ill務(wù)端和至少兩個客戶端，所 述至少兩個客戶端包括客戶發(fā)送端和客戶接收端，其特征在于，所述方法包括 以下步驟A. 客戶發(fā)送端建立會話，采集語音；B. 客戶發(fā)送端通過多線程處理方法和編碼算法對語音數(shù)據(jù)進行編碼；C. 客戶發(fā)送端對編碼后的數(shù)據(jù)進行封包，構(gòu)造數(shù)據(jù)包；D. 客戶發(fā)送端發(fā)送數(shù)據(jù)包到服務(wù)端，服務(wù)端接收數(shù)據(jù)包并分發(fā)給客戶接收端；E. 客戶接收端接收數(shù)據(jù)包，通過多線程處理方法和編碼算法對數(shù)據(jù)包進行 解碼，生成語音。
5、 根據(jù)權(quán)利要求4所述的PoC業(yè)務(wù)處理方法，其特征在于，所述編碼算 法為AMR算法。
6、 根據(jù)權(quán)利要求4所述的PoC業(yè)務(wù)處理方法，其特征在于，所述步驟C進一步包括對編碼后的語音數(shù)據(jù)封包時采用至少兩個幀構(gòu)造一個數(shù)據(jù)包。
7、 根據(jù)權(quán)利要求4所述的PoC業(yè)務(wù)處理方法，其特征在于，所述步驟D 進一步包括Dl .客戶發(fā)送端采用"重發(fā)控制"方式將數(shù)據(jù)包發(fā)送給服務(wù)端； D2.服務(wù)端采用"重發(fā)控制"方式將數(shù)據(jù)包分發(fā)給客戶接收端。
8、 根據(jù)權(quán)利要求7所述的PoC業(yè)務(wù)處理方法，其特征在于，所述步驟 Dl中的"重發(fā)控制"方式為Dl 1 .客戶發(fā)送端發(fā)送數(shù)據(jù)包給服務(wù)端，全部的數(shù)據(jù)包發(fā)送完畢后發(fā)送"釋 放發(fā)言"請求到服務(wù)端；D12.服務(wù)端收到數(shù)據(jù)包并保存，收到"釋放發(fā)言"請求時檢查文件是否完整；D13.若文件完整，服務(wù)端發(fā)送"擴充TBCP消息"通知給客戶發(fā)送端結(jié)束 會話；D14.若文件不完整，服務(wù)端發(fā)送"擴充TBCP消息"給客戶發(fā)送端，請求 發(fā)送丟失的數(shù)據(jù)，重復(fù)Dll。
9、 根據(jù)權(quán)利要求7所述的PoC業(yè)務(wù)處理方法，其特征在于，所述步驟 Dl中的"重發(fā)控制"方式為D21 .服務(wù)端分發(fā)數(shù)據(jù)包給客戶接收端，發(fā)送完畢后向客戶接收端發(fā)送"會 話空閑"消息；D22.接收端收到數(shù)據(jù)包后解碼恢復(fù)文件，收到"會話空閑"消息時檢查文件 是否完整；D23.若文件完整，接收端結(jié)束會話；D24.若文件不完整，接收端發(fā)送"擴充TBCP消息"給服務(wù)端，請求發(fā)送丟 失的數(shù)據(jù)，重復(fù)D21。
10、 4艮據(jù)權(quán)利要求4所述的PoC業(yè)務(wù)處理方法，其特征在于，所述步驟E 進一步包括客戶接收端收到語音數(shù)據(jù)包后，參考該數(shù)據(jù)包的時間戳和包序號 將其插入緩沖區(qū)中或丟棄，采用更新播放隊列的方式生成語音。
全文摘要
本發(fā)明涉及網(wǎng)絡(luò)通信技術(shù)領(lǐng)域，提供了一種PoC業(yè)務(wù)處理方法及系統(tǒng)，所述方法包括以下步驟A.客戶發(fā)送端建立會話，采集語音；B.客戶發(fā)送端通過多線程處理方法和編碼算法對語音數(shù)據(jù)進行編碼；C.客戶發(fā)送端對編碼后的數(shù)據(jù)進行封包，構(gòu)造數(shù)據(jù)包；D.客戶發(fā)送端發(fā)送數(shù)據(jù)包到服務(wù)端，服務(wù)端接收數(shù)據(jù)包并分發(fā)給客戶接收端；E.客戶接收端接收數(shù)據(jù)包，通過多線程處理方法和編碼算法對數(shù)據(jù)包進行解碼，生成語音。本發(fā)明通過采用多線程處理方法和AMR算法進行編碼和解碼數(shù)據(jù)包，降低了通話延遲，提高了通話效率。另外，本發(fā)明還通過“重發(fā)控制”方式實現(xiàn)文件的發(fā)送與接收，從而保證了文件傳輸?shù)耐暾浴?br> 文檔編號H04W28/02GK101527885SQ20081006547
公開日2009年9月9日 申請日期2008年3月3日 優(yōu)先權(quán)日2008年3月3日
發(fā)明者鄭水金 申請人:深圳市艾派應(yīng)用系統(tǒng)有限公司