專利名稱：一種高效的按鍵通話方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通訊領(lǐng)域，特別是涉及一種基于的移動通信網(wǎng)絡(luò)分組域的會話協(xié)商和音頻媒體數(shù)據(jù)傳輸?shù)念I(lǐng)域。
背景技術(shù)：
SIP是一個應(yīng)用層的信令控制協(xié)議。用于創(chuàng)建、修改和釋放一個或多個參與者的會話。這些會話可以好似Internet多媒體會議、IP電話或多媒體分發(fā)。會話的參與者可以通過組播(multicast)、網(wǎng)狀單播(unicast)或兩者的混合體進行通信。SIP它既不是會話描述協(xié)議，也不提供會議控制功能。為了描述消息內(nèi)容的負(fù)載情況和特點，SIP使用Internet 的會話描述協(xié)議(SDP)來描述終端設(shè)備的特點。SIP自身也不提供服務(wù)質(zhì)量(QoS)，它與負(fù)責(zé)語音質(zhì)量的資源保留設(shè)置協(xié)議(RSVP)互操作。
在進行實時傳輸媒體數(shù)據(jù)時，使用RTP協(xié)議與SIP合作使用。RTCP控制協(xié)議需要與RTP數(shù)據(jù)協(xié)議一起配合使用，RTP本身并不能為按序傳輸數(shù)據(jù)包提供可靠的保證，也不提供流量控制和擁塞控制，這些都由RTCP來負(fù)責(zé)完成。通常RTCP會采用與RTP相同的分發(fā)機制，向會話中的所有成員周期性地發(fā)送控制信息，應(yīng)用程序通過接收這些數(shù)據(jù)，從中獲取會話參與者的相關(guān)資料，以及網(wǎng)絡(luò)狀況、分組丟失概率等反饋信息，從而能夠?qū)Ψ?wù)質(zhì)量進行控制或者對網(wǎng)絡(luò)狀況進行診斷。
在現(xiàn)在的OMA規(guī)范中PoC業(yè)務(wù)就是使用的SIP加RTP/RTCP的方案，SIP用于會話的協(xié)商，RTP/RTCP用于流媒體數(shù)據(jù)的傳輸。
對于PoC業(yè)務(wù)的使用場景主要在通話比較頻繁的地方或者偏僻的郊外，如行業(yè)用戶中的電力、物流、水 利等，這些地方偏僻、流動性大，不可能有專用網(wǎng)絡(luò)，接入方式使用最多的就是現(xiàn)在覆蓋比較好的移動通信網(wǎng)絡(luò)，所以3G分組域接入成了最常用的接入方式。
在現(xiàn)有的產(chǎn)品中，受限于帶寬、PDP激活時長等的限制導(dǎo)致會話建立時間太長、語音延時明顯的問題，分析其原因主要是由幾個方面引起，一個是PDP激活的時長，這個由移動網(wǎng)絡(luò)決定不在此討論。一個是通過SIP協(xié)議做會話協(xié)商的時間太長，由于SIP協(xié)議數(shù)據(jù)量太大，做會話協(xié)商需要的時間比較長。另外一個是做媒體流傳輸?shù)陌?，?dǎo)致傳輸中有大量的包頭數(shù)據(jù)和建立連接次數(shù)太多消耗時間，本發(fā)明就是針對后兩個問題做優(yōu)化來減少按鍵通話的會話建立延時和傳輸效率地下。發(fā)明內(nèi)容
本發(fā)明所要解決的技術(shù)問題是在原有RTCP協(xié)議的基礎(chǔ)上作了如下改進，使用RTP 協(xié)議進行媒體數(shù)據(jù)傳輸，RTCP協(xié)議在實現(xiàn)本身功能的同時進行擴展，使其同時能夠完成會話協(xié)商的功能來替代SIP會話協(xié)商；并對傳輸?shù)拿襟w包進行打包處理使相同時間發(fā)送的包的數(shù)量最少。
為實現(xiàn)上述發(fā)明目的，本發(fā)明提供一個重新封裝的RTP/RTCP協(xié)議庫，及對應(yīng)的 PoC服務(wù)器，包括PoC客戶端和PoC服務(wù)器
所述PoC客戶端，用于最終用戶使用，手機終端中的PoC軟件通過移動通訊網(wǎng)絡(luò)的分組域連接，注冊使用SIP消息在服務(wù)器中注冊，移動通訊網(wǎng)絡(luò)分組域連接為了節(jié)約資源， 防止沒有數(shù)據(jù)的空連接太多都設(shè)置了連接時長限制，在一段時間內(nèi)如果沒有數(shù)據(jù)傳輸就會斷開連接，所以客戶端軟件在注冊成功后為了維持連接需要發(fā)送心跳消息，心跳消息的間隔時長根據(jù)不同地方的網(wǎng)絡(luò)設(shè)置有區(qū)別，心跳消息是通過RTP和RTCP消息發(fā)送，發(fā)送IDLE 消息，不作其他功能，只是維持連接使用。根據(jù)用戶的操作發(fā)起對PoC聯(lián)系人的按鍵通話操作，發(fā)起呼叫的主叫方通過RTCP的格式和通道，把RTCP包的APP字段特殊定義成204， subtype字段定義成不同的會話控制請求類型，把NAME定義成“PoCl”，這樣整個會話協(xié)商功能的包就完成了，通過RTCP通道發(fā)送，并通過接受RTCP通道的消息來完成會話協(xié)商，這樣在；
所述PoC服務(wù)器，用于對PoC客戶端服務(wù)，支撐PoC業(yè)務(wù)的使用。
本發(fā)明還提供一套打包和解包的方法，包括
1.本系統(tǒng)使用AMR編碼格式5. 15kbps的比特率，這個比特率對于人說話的聲音清晰度是夠用的，音頻數(shù)據(jù)采集是20ms —組數(shù)據(jù)，在編碼后一組數(shù)據(jù)是13字節(jié)，在對音頻數(shù)據(jù)打包處理時不是一組數(shù)據(jù)一發(fā)，而是采用8組數(shù)據(jù)編碼完成后組合在一起發(fā)送，這樣處理主要考慮兩方便，一個是數(shù)據(jù)不能太短，太短發(fā)送頻率太大，這樣建立連接和包頭數(shù)據(jù)冗余太多，影響發(fā)送效率；數(shù)據(jù)不能太長，太長后延時就長，另外要一個分組域的包能發(fā)送完成，如果分包處理就會有延時。
2.解包時，服務(wù)器或客戶端會先根據(jù)收到包的長度，來判斷該包構(gòu)成，然后再解包恢復(fù)媒體數(shù)據(jù)。


為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單的介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其他的附圖。
圖1為本發(fā)明實施中消息控制圖2為本發(fā)明實施中的媒體數(shù)據(jù)組包發(fā)送格式。
具體實施方式
為使本發(fā)明的上述目的、特征和優(yōu)點能夠更加明顯易懂，下面結(jié)合附圖和具體實施方式
對本發(fā)明作進一步詳細的說明。顯然，所描述的實施例僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。
本發(fā)明提供一個重新封裝的RTP/RTCP協(xié)議庫，其中改進點包括
RTCP是發(fā)言權(quán)控制協(xié)議，是基于RTCP應(yīng)用包的(RTCP = APP)，與其他的RTCP包發(fā)送到相同的UDP端口。
RTCP定義的控制TBCP消息包括
· TBCP Talk Burst Request-客戶端向服務(wù)器端請求發(fā)言權(quán)允許
表I “TBCP Talk Burst請求消息”說明了消息的內(nèi)容。0123 01234567890123456789012345678901|V=2|P|0 O O O 0| PT=APP=204 丨lengthH—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I—I1SSRC of PoC Client requesting permission to send a talk burstIname=PoClI Option ID I Option Length I IOption ValueI Option ID I Option Length 丨 Option Value
在Subtype域中的下列比特格式應(yīng)該被用來作為TBCP Talk Burst請求信息00000。SSRC域應(yīng)該攜帶申請發(fā)言權(quán)的PoC用戶的SSRC值。在TBCP Talk Burst請求消息中，可以包含一個或多個可選域。每個TBCPTalk Burst請求消息可選域應(yīng)該包含三個子域。
第一個子域是可選ID子域。這個可選ID子域應(yīng)該標(biāo)識選來作為8-bit可選ID 的選項。
第二個子域是可選長度子域?？蛇x長度子域應(yīng)該由一個字節(jié)組成，說明整個可選域的長度?？蛇x長度子域的值應(yīng)該等于可選ID子域、可選長度子域和可選值子域字節(jié)數(shù)的總和。
注意這個長度沒有必要乘以4。
第三個子域是可選值子域。這個值子域應(yīng)該包含一個字節(jié)數(shù)的整數(shù)值。這個子域的格式和值是依賴于應(yīng)用選項的。
下面的定義了 TBCP Talk Burst請求信息選項
如果PoC服務(wù)器收到重復(fù)的TBCP Talk Burst request，PoC服務(wù)器按照正常的處理方法處理請求。
] TBCP Talk Burst Granted-服務(wù)器端通知客戶端允許其講話表2 “TBCP Talk Burst允許消息”顯示了消息的內(nèi)容。
[003權(quán)利要求
1.一種基于RTCP的無線對講通訊系統(tǒng)會話控制協(xié)議，其特征在于，使用封裝好的RTCP 協(xié)議進行擴展來代替SIP協(xié)議控制會話狀態(tài)。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括使用RTCP協(xié)議作為控制信號傳輸?shù)膮f(xié)議，使用RTCP協(xié)議作為媒體流傳輸?shù)膮f(xié)議；定義的RTCP信號包括CONNECT， DISCONNECT, ACK, GRANTED, REQUEST, RELEASE, IDLE。
3.一種基于MS的無線對講通訊系統(tǒng)媒體傳輸格式的優(yōu)化，其特征在于，降低RTP協(xié)議包的傳輸頻率，提高傳輸效率。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，還包括按照20ms—個音頻采集編碼數(shù)據(jù)包來打包數(shù)據(jù),然后每次把多個(現(xiàn)在使用8個)相鄰包的數(shù)據(jù)合成一個包傳輸出去(現(xiàn)在使用的8個包打包，傳輸周期為160ms)。
全文摘要
本發(fā)明公開了一種按鍵通話中呼叫建立的時間太長的問題的解決方案。針對現(xiàn)有OMA的PoC(push to talk over celluler)規(guī)范中首次呼叫建立延時、通話延時時間比較長的問題，對會話控制協(xié)議進行修改后傳輸?shù)暮艚锌刂茀f(xié)議數(shù)據(jù)量減少，并對音頻數(shù)據(jù)進行打包傳輸，達到減少延時的目的。
文檔編號H04W4/10GK103024681SQ201110282500
公開日2013年4月3日 申請日期2011年9月20日 優(yōu)先權(quán)日2011年9月20日
發(fā)明者梁平, 李大軍, 寧學(xué)軍 申請人:佳都新太科技股份有限公司