專利名稱：一種實(shí)現(xiàn)確認(rèn)PoC業(yè)務(wù)接收效果的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及PoC(PTT over cellular)技術(shù)領(lǐng)域，特別是指一種實(shí)現(xiàn)確認(rèn)PoC業(yè)務(wù)接收效果的方法。
背景技術(shù)：
PTT(Push to Talk)是一種即按即說(shuō)的語(yǔ)音業(yè)務(wù)，即通過(guò)按住功能鍵實(shí)現(xiàn)通信的一種半雙工語(yǔ)音業(yè)務(wù)，目前該業(yè)務(wù)有很多種實(shí)現(xiàn)方式，如集成數(shù)字增強(qiáng)網(wǎng)絡(luò)(iDEN)業(yè)務(wù)以及陸地中繼無(wú)線電技術(shù)(Tetra)業(yè)務(wù)等。
PoC(PTT over cellular)是開放移動(dòng)聯(lián)盟組織(OMA，open mobilealliance)定義的在分組網(wǎng)絡(luò)上實(shí)現(xiàn)的PTT業(yè)務(wù)，其采用分組語(yǔ)音(VoIP)以及半雙工的實(shí)現(xiàn)方式，能夠低成本、高效率地滿足用戶實(shí)時(shí)通信的需求。PoC業(yè)務(wù)具有如下特點(diǎn)1)通話時(shí)不需要撥號(hào)，按住特殊鍵即可實(shí)現(xiàn)語(yǔ)音通信；2)能夠?qū)崿F(xiàn)組播功能，即一個(gè)用戶說(shuō)話時(shí)多個(gè)用戶同時(shí)收聽；3)組播業(yè)務(wù)的群組可以是預(yù)先定義的，也可以是臨時(shí)定義的；4)在通話過(guò)程中采用半雙工模式，被叫用戶在接聽時(shí)不能發(fā)言；5)用戶一直在線，建立通話的時(shí)間短，其快于撥號(hào)；PoC業(yè)務(wù)引入了一種新的通信模式，是現(xiàn)有移動(dòng)系統(tǒng)以及傳統(tǒng)語(yǔ)音呼叫系統(tǒng)所無(wú)法提供的，PoC在滿足實(shí)時(shí)呼叫的同時(shí)，能夠較少地占用系統(tǒng)資源。
圖1所示為PoC業(yè)務(wù)開展模式圖。具有PoC能力終端的用戶與PoC業(yè)務(wù)的供應(yīng)商進(jìn)行簽約，以獲得使用PoC業(yè)務(wù)的許可；PoC用戶通過(guò)PoC服務(wù)器與其它PoC用戶建立群組關(guān)系；PoC用戶通過(guò)按功能鍵要求發(fā)言從而實(shí)現(xiàn)PoC業(yè)務(wù)。
假設(shè)客戶端A(ClientA)申請(qǐng)注冊(cè)完畢后，接收到已注冊(cè)的ClientB發(fā)出的建立連接的邀請(qǐng)，則在ClientB與ClientA之間建立起用戶面承載后，即可開始會(huì)話。圖2所示為實(shí)現(xiàn)PoC業(yè)務(wù)的流程圖。
步驟201，ClientA通過(guò)SIP核心網(wǎng)(SIP core)向PoC服務(wù)器(PoC Server)發(fā)送SIP注冊(cè)請(qǐng)求消息，該請(qǐng)求消息中包括鑒權(quán)信息和參數(shù)協(xié)商信息；步驟202，SIP core完成對(duì)ClientA的鑒權(quán)后，向ClientA發(fā)送200OK確認(rèn)消息；步驟203，當(dāng)ClientB希望與ClientA進(jìn)行會(huì)話時(shí)，首先向PoC server發(fā)送邀請(qǐng)(invite)消息，邀請(qǐng)ClientA與PoC server建立連接；步驟204，PoC server通過(guò)SIP core將邀請(qǐng)消息轉(zhuǎn)發(fā)給ClientA；步驟205，ClientA接收到邀請(qǐng)消息后，通過(guò)SIP core將200OK發(fā)送給PoC server；步驟206，PoC server接收到來(lái)自ClientA的200OK信息后，將該信息轉(zhuǎn)發(fā)給ClientB；步驟207，ClientB向PoC server回復(fù)響應(yīng)消息；步驟208，PoC server將來(lái)自ClientB的響應(yīng)消息通過(guò)SIP core轉(zhuǎn)發(fā)給ClientA；步驟209，ClientA接收到來(lái)自ClientB的響應(yīng)消息后，與PoC server建立Client面承載，此時(shí)，ClientA與ClientB之間可通過(guò)PoC server建立會(huì)話連接。
目前根據(jù)OMA的定義，PoC用戶只能進(jìn)行半雙工的語(yǔ)音業(yè)務(wù)即用戶在收聽時(shí)不能夠發(fā)言，發(fā)言時(shí)需要先申請(qǐng)，獲得發(fā)言權(quán)后，才能進(jìn)行發(fā)言，但發(fā)言的同時(shí)不能接收其它用戶的發(fā)言。
現(xiàn)有的PoC雖然滿足了用戶對(duì)于PTT業(yè)務(wù)的基本需求，但如果一個(gè)用戶對(duì)一個(gè)群組發(fā)送會(huì)話后，由于網(wǎng)絡(luò)覆蓋或者其他原因，希望確認(rèn)所有或部分接聽客戶端的接收效果時(shí)，根據(jù)現(xiàn)有方案首先需要發(fā)言用戶完成發(fā)言后，通過(guò)語(yǔ)音要求接聽用戶確認(rèn)是否正確收到信息，而被要求的接聽用戶只能通過(guò)按功能鍵搶占發(fā)言的方式，來(lái)通知發(fā)言客戶端其自身的接聽效果。這樣不但會(huì)對(duì)系統(tǒng)造成很大的沖擊，而且這種確認(rèn)方式也讓發(fā)言客戶端無(wú)法方便、準(zhǔn)確地記錄下確認(rèn)信息，從而給業(yè)務(wù)的應(yīng)用帶來(lái)了很大的不便。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的目的在于提供一種實(shí)現(xiàn)確認(rèn)PoC業(yè)務(wù)接聽效果的方法，既能夠便于發(fā)言者記錄確認(rèn)信息，又能避免由于很多用戶搶占發(fā)言權(quán)而對(duì)系統(tǒng)造成的沖擊。
為達(dá)到上述目的，本發(fā)明的技術(shù)方案是這樣實(shí)現(xiàn)的一種實(shí)現(xiàn)確認(rèn)PoC業(yè)務(wù)接收效果的方法，該方法包括以下步驟a、發(fā)言客戶端在發(fā)送報(bào)告消息SR中設(shè)置要求接聽客戶端發(fā)送接收?qǐng)?bào)告消息的標(biāo)識(shí)信息；b、發(fā)言客戶端在發(fā)言結(jié)束后請(qǐng)求PoC服務(wù)器將SR消息轉(zhuǎn)發(fā)給接聽客戶端；c、接聽客戶端接收到PoC服務(wù)器轉(zhuǎn)發(fā)的SR報(bào)文后，根據(jù)該消息中的接收?qǐng)?bào)告消息的標(biāo)識(shí)信息判斷自身是否需要發(fā)送RR報(bào)文，如果是，則向PoC服務(wù)器發(fā)送RR報(bào)文后，執(zhí)行步驟d，否則不做任何處理；d、根據(jù)接聽客戶端所發(fā)送的RR報(bào)文，發(fā)言客戶端確認(rèn)接聽客戶端的接收效果。
較佳地，步驟c所述接聽客戶端判斷自身是否需要發(fā)送RR報(bào)文的方法包括以下步驟c1、根據(jù)SR報(bào)文中的接收?qǐng)?bào)告消息的標(biāo)識(shí)信息判斷是否要求所有的接聽客戶端發(fā)送RR報(bào)文，如果是，則向PoC服務(wù)器發(fā)送RR報(bào)文，否則執(zhí)行步驟c2；c2、判斷是否要求部分接聽客戶端發(fā)送RR報(bào)文，如果不是，則不需要自身發(fā)送RR報(bào)文，如果是，則進(jìn)一步判斷需要發(fā)送RR報(bào)文的用戶名中是否包含自身的用戶名，如果是，則向PoC服務(wù)器發(fā)送RR報(bào)文，否則不需要自身發(fā)送RR報(bào)文。
較佳地，步驟d所述根據(jù)接聽客戶端所發(fā)送的RR報(bào)文，發(fā)言客戶端確認(rèn)接聽客戶端接收效果的方法是發(fā)言客戶端接收到PoC服務(wù)器轉(zhuǎn)發(fā)的RR報(bào)文后，首先判斷所接收到的報(bào)文是否屬于本次發(fā)言的語(yǔ)音包，如果是，再根據(jù)接收到的RR報(bào)文計(jì)算出丟包率和到達(dá)間隔抖動(dòng)時(shí)間確認(rèn)各個(gè)發(fā)送RR報(bào)文的接聽客戶端的接收效果。
較佳地，所述PoC服務(wù)器給發(fā)言客戶端轉(zhuǎn)發(fā)RR報(bào)文的方法是PoC服務(wù)器接收到來(lái)自接聽客戶端的RR報(bào)文后，首先進(jìn)行緩存，然后再按照RTCP協(xié)議的定義，將所收集到的RR報(bào)文組裝成一個(gè)RR報(bào)文后，發(fā)送給發(fā)言客戶端。
較佳地，所述緩存的方式為PoC服務(wù)器每隔一段已設(shè)定的時(shí)間發(fā)送一次已組裝的RR報(bào)文，或者，每收集到已設(shè)定個(gè)數(shù)的RR報(bào)文，發(fā)送一次已組裝的RR報(bào)文。
較佳地，所述發(fā)言客戶端判斷所接收到的報(bào)文是否屬于本次發(fā)言的語(yǔ)音包的方法是根據(jù)RR報(bào)文中的extended highest sequence number received字段判斷該RR報(bào)文是否屬于本次發(fā)言所產(chǎn)生的語(yǔ)音包的序號(hào)范圍之內(nèi)，如果是，則屬于本次發(fā)言所產(chǎn)生的語(yǔ)音包，否則，不屬于本次發(fā)言所產(chǎn)生的語(yǔ)音包。
較佳地，步驟d所述根據(jù)接聽客戶端所發(fā)送的RR報(bào)文，發(fā)言客戶端確認(rèn)接聽客戶端的接收效果的方法是由PoC服務(wù)器根據(jù)來(lái)自接聽客戶端的RR報(bào)文計(jì)算出各個(gè)發(fā)送RR報(bào)文的接聽客戶端的丟包率和到達(dá)間隔抖動(dòng)時(shí)間，并將已計(jì)算出的丟包率和到達(dá)間隔抖動(dòng)時(shí)間轉(zhuǎn)換為接收質(zhì)量等級(jí)發(fā)送給發(fā)言客戶端，由發(fā)言客戶端根據(jù)該接收質(zhì)量等級(jí)確認(rèn)各個(gè)發(fā)送RR報(bào)文的接聽客戶端的接收效果。
較佳地，該方法進(jìn)一步包括發(fā)言客戶端提示發(fā)言用戶向接收效果較差的接聽客戶端重新發(fā)送語(yǔ)音包。
本發(fā)明由發(fā)言客戶端在發(fā)送報(bào)告消息SR中設(shè)置要求接聽客戶端發(fā)送接收?qǐng)?bào)告消息的標(biāo)識(shí)信息，發(fā)言客戶端在發(fā)言結(jié)束后請(qǐng)求PoC服務(wù)器將SR消息轉(zhuǎn)發(fā)給接聽客戶端；接聽客戶端接收到PoC服務(wù)器轉(zhuǎn)發(fā)的SR報(bào)文，根據(jù)該報(bào)文中的接收?qǐng)?bào)告消息的標(biāo)識(shí)信息判斷出自身需要發(fā)送RR報(bào)文后，再向PoC服務(wù)器發(fā)送RR報(bào)文，根據(jù)接聽客戶端所發(fā)送的RR報(bào)文，發(fā)言客戶端確認(rèn)接聽客戶端的接收效果。應(yīng)用本發(fā)明，不但實(shí)現(xiàn)了發(fā)言客戶端迅速準(zhǔn)確地確認(rèn)接聽客戶端的接聽效果，而且避免了由于很多用戶搶占發(fā)言權(quán)而對(duì)系統(tǒng)造成的沖擊。另外，發(fā)言用戶可以向接收效果不好的接聽客戶端重新發(fā)送語(yǔ)音包。本發(fā)明能夠滿足具有較高可靠性要求的應(yīng)用業(yè)務(wù)。同時(shí)，運(yùn)營(yíng)商還可以對(duì)此項(xiàng)服務(wù)進(jìn)行計(jì)費(fèi)，以增加其收入。


圖1所示為PoC業(yè)務(wù)開展模式圖；圖2所示為實(shí)現(xiàn)PoC業(yè)務(wù)的流程圖；圖3所示為應(yīng)用本發(fā)明一實(shí)施例的業(yè)務(wù)確認(rèn)流程圖。
具體實(shí)施例方式
為使本發(fā)明的技術(shù)方案更加清楚，下面結(jié)合附圖及具體實(shí)施例再對(duì)本發(fā)明做進(jìn)一步詳細(xì)說(shuō)明。
本發(fā)明的思路是由發(fā)言客戶端在發(fā)送報(bào)告消息SR中設(shè)置要求接聽客戶端發(fā)送接收?qǐng)?bào)告消息的標(biāo)識(shí)信息；發(fā)言客戶端在發(fā)言結(jié)束后請(qǐng)求PoC服務(wù)器將SR消息轉(zhuǎn)發(fā)給接聽客戶端；接聽客戶端接收到PoC服務(wù)器轉(zhuǎn)發(fā)的SR報(bào)文，根據(jù)該報(bào)文中的接收?qǐng)?bào)告消息的標(biāo)識(shí)信息判斷出自身需要發(fā)送RR報(bào)文后，再向PoC服務(wù)器發(fā)送RR報(bào)文，根據(jù)接聽客戶端所發(fā)送的RR報(bào)文，發(fā)言客戶端確認(rèn)接聽客戶端的接收效果。
本發(fā)明使用實(shí)時(shí)傳輸協(xié)議(RTP)和實(shí)時(shí)傳輸控制協(xié)議(RTCP)作為語(yǔ)音流的傳輸和控制協(xié)議。下面先對(duì)RTP和RTCP做一簡(jiǎn)單介紹。
RTP協(xié)議是針對(duì)多媒體數(shù)據(jù)流的一種傳輸協(xié)議。該協(xié)議被定義為在一對(duì)一或一對(duì)多的傳輸情況下工作，其目的是提供時(shí)間信息和實(shí)現(xiàn)流同步。RTP協(xié)議本身并不能為按順序傳送的數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。
RTCP協(xié)議與RTP協(xié)議一起，提供流式媒體數(shù)據(jù)的擁塞控制和流量控制服務(wù)。RTCP包中含有已發(fā)送數(shù)據(jù)包的數(shù)量、丟失數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料，將RTP和RTCP配合使用，能得到有效的反饋和最小的開銷，從而使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實(shí)時(shí)數(shù)據(jù)。
RTCP協(xié)議中包括以下幾種消息類型發(fā)送報(bào)告消息(SR)，該消息是活動(dòng)的用戶對(duì)發(fā)出業(yè)務(wù)流的統(tǒng)計(jì)，其報(bào)文結(jié)構(gòu)如表1所示。其中，V表示版本(version)；P表示填充(padding)；RC表示接收?qǐng)?bào)告計(jì)數(shù)(reception report count)；PT表示包類型(packet type)，用于指明RTCP類型，其中十進(jìn)制的200代表SR；fraction lost表示丟失包數(shù)，即上一次SR或接收?qǐng)?bào)告消息(RR)發(fā)送之后丟失的包數(shù)。表1邊上的header表示報(bào)文頭，sender info表示發(fā)送者信息，report block表示報(bào)告塊。0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+header |V=2|P|RC | PT=SR=200 |長(zhǎng)度(length) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 發(fā)送者的同步源標(biāo)志(SSRC of sender)|+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+sender |網(wǎng)絡(luò)時(shí)間戳(高位字節(jié)) (NTP timestamp，most significant word) |info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|網(wǎng)絡(luò)時(shí)間戳(低位字節(jié)) (NTP timestamp，least significant word) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| RTP時(shí)戳(RTP timestamp) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 發(fā)送者的包數(shù)(sender’s packet count)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 發(fā)送者的字節(jié)數(shù)(sender’s octet count) |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report | 第一同步源標(biāo)志(SSRC_1(SSRC of first source))|block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+1| fraction lost |累計(jì)丟包數(shù)(cumulative number of packets lost) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 接收到的擴(kuò)展的最高序列號(hào) || (extended highest sequence number received) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 到達(dá)間隔抖動(dòng)(interarrival jitter)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|上一SR報(bào)文時(shí)戳(last SR(LSR)) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 自上一SR的時(shí)間(delay since last SR(DLSR)) |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report | 第二同步源標(biāo)志(SSRC_2(SSRC of second source)) |block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| 特殊的擴(kuò)展字段(profile-specific extensions) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+表1接收?qǐng)?bào)告消息(RR)，該消息是不活動(dòng)的用戶對(duì)接收業(yè)務(wù)流的統(tǒng)計(jì)，其報(bào)文結(jié)構(gòu)如表2所示。其中的英文縮寫以及英文字段參見表1所示相應(yīng)內(nèi)容。0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+header |V=2|P|RC | PT=RR=201 | length|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SSRC of packet sender |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report | SSRC_1(SSRC of first source) |block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+1| fraction lost | cumulative number of packets lost |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| extended highest sequence number received |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| interarrival jitter |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| last SR(LSR) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| delay since last SR(DLSR) |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report | SSRC_2(SSRC of second source) |block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| profile-specific extensions |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+表2源描述消息(SDES)，該消息用于標(biāo)識(shí)用戶，其報(bào)文結(jié)構(gòu)如表3所示。其中Chunk表示塊，其它的英文縮寫以及英文字段參見表1所示相應(yīng)內(nèi)容。0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+header |V=2|P|SC | PT=SDES=202 | length|+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+chunk | SSRC/CSRC_1 |1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SDES items || ... |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+chunk | SSRC/CSRC_2 |2+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SDES items || ... |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+＝+表3圖3所示為應(yīng)用本發(fā)明一實(shí)施例的業(yè)務(wù)確認(rèn)流程圖。假設(shè)某個(gè)群組中有Client A、Client B、Client C和Client D四個(gè)用戶，且Client A為發(fā)言客戶端，其余為接聽客戶端。在本實(shí)施例中，使用RTP和RTCP作為語(yǔ)音流的傳輸和控制協(xié)議。
步驟301，Client A預(yù)先設(shè)置要求接收用戶發(fā)送回執(zhí)的標(biāo)識(shí)RRflag，該標(biāo)識(shí)位于SR報(bào)文的特殊的擴(kuò)展字段(profile-specific extensions)字段中，該RRflag的格式如表4所示

表4在本實(shí)施例中規(guī)定RRflag＝1；f有四個(gè)取值，其具體取值含義如下00————不需接聽客戶端發(fā)送RR報(bào)文；01————需要部分接聽客戶端發(fā)送RR報(bào)文；10————需要全組所有的接聽客戶端均發(fā)送RR報(bào)文；11————無(wú)效；其余為保留字節(jié)；
如果要求組內(nèi)所有接聽客戶端全部發(fā)送RR報(bào)文，則在SDES報(bào)文內(nèi)SDES items字段的后續(xù)中不需要增加任何內(nèi)容，如果要求組內(nèi)部分接聽客戶端反饋RR報(bào)文，則在SDES報(bào)文內(nèi)SDES items字段中提供需要反饋接聽客戶端的用戶名，該用戶名為用戶加入群組時(shí)所登記的用戶名；提供需要反饋接聽客戶端的用戶名格式如表5所示

表5步驟302，Client A向PoC server申請(qǐng)發(fā)言；步驟303，PoC server完成對(duì)Client A的鑒權(quán)后，向用戶A發(fā)送成功的響應(yīng)消息(RSP)，允許用戶A發(fā)言；步驟304，PoC server給所有的接聽客戶端發(fā)送系統(tǒng)占用的通知消息(OCCUPIED_IND)；步驟305，Client A向PoC server發(fā)送語(yǔ)音包，并由PoC server將ClientA所發(fā)送的語(yǔ)音包轉(zhuǎn)發(fā)給Client B、C、D；同時(shí)，Client A記錄本次發(fā)言所產(chǎn)生語(yǔ)音包的序號(hào)范圍，即利用SR報(bào)文中的接收到的擴(kuò)展的最高序列號(hào)(extended highest sequence number received)字段，記錄本次發(fā)言所產(chǎn)生語(yǔ)音包的序號(hào)范圍，extended highest sequence number received字段為32比特(bit)，每次發(fā)言都以上一次發(fā)言結(jié)束的包序號(hào)作為起始，等溢出后，再重新計(jì)數(shù)；步驟306，Client A發(fā)言結(jié)束后，釋放發(fā)言請(qǐng)求(Floor)；步驟307，Client A發(fā)送SR報(bào)文給PoC server，要求獲取接聽客戶端的反饋信息，該SR報(bào)文中包含Client A的標(biāo)識(shí)信息；步驟308，PoC server將來(lái)自Client A的SR報(bào)文轉(zhuǎn)發(fā)給所有的接聽客戶端；步驟309，Client B、C、D接收到來(lái)自PoC server的SR報(bào)文后，對(duì)該報(bào)文中的回執(zhí)標(biāo)識(shí)RRflag進(jìn)行判斷，并根據(jù)f的具體取值進(jìn)行處理；
如果f的取值為00，則所有接聽客戶端不發(fā)送RR報(bào)文；如果f的取值為0l，則將SEDS中提供的需要反饋用戶的用戶名與自身的用戶名相比較，如相同，則發(fā)送RR報(bào)文給PoC server，如不同，則不需要發(fā)送RR報(bào)文；如果f的取值為10，則所有接聽客戶端全部發(fā)送RR報(bào)文給PoC server；如果f的取值為11，則該標(biāo)識(shí)無(wú)效，所有接聽客戶端不發(fā)送RR報(bào)文；在本實(shí)施例中，假設(shè)預(yù)先設(shè)置f的值為01，且SEDS中提供的用戶名為Client B和Client C，即只有Client B和Client C發(fā)送RR報(bào)文，且所發(fā)送的RR報(bào)文中包含自身的標(biāo)識(shí)；步驟310，PoC server接收到來(lái)自Client B、C的RR報(bào)文后，為了節(jié)約帶寬，首先進(jìn)行緩存，然后再按照RTCP的定義，將所收集到的RR報(bào)文組裝成一個(gè)RR報(bào)文后，發(fā)送給Client A；上述緩存方式為預(yù)先設(shè)定一段等待的時(shí)間，如5秒，則PoC server每5秒向Client A發(fā)送一次按照RTCP定義已組裝好的RR報(bào)文；或者，上述緩存方式為預(yù)先設(shè)定從接聽客戶端收集到的RR報(bào)文的個(gè)數(shù)，如31個(gè)，則PoCserver每收集到31個(gè)來(lái)自接聽客戶端的RR報(bào)文后，向Client A發(fā)送一次按照RTCP定義已組裝好的RR報(bào)文；步驟311，Client A接收到來(lái)自PoC server的RR報(bào)文后，首先根據(jù)RR報(bào)文中的extended highest sequence number received字段判斷該RR報(bào)文是否屬于本次發(fā)言所產(chǎn)生的語(yǔ)音包的序號(hào)范圍之內(nèi)，如果不是，則不做任何處理，如果是，則根據(jù)RR報(bào)文中的接收總包數(shù)、到達(dá)間隔抖動(dòng)等參數(shù)計(jì)算出本次發(fā)言中各個(gè)發(fā)送RR報(bào)文的接聽客戶端的丟包率以及抖動(dòng)時(shí)間，并由此確認(rèn)該各個(gè)接聽客戶端的接收效果。
當(dāng)某個(gè)或某幾個(gè)接聽客戶端的接收效果較差時(shí)，Client A可以采用閃爍光標(biāo)等方式提示用戶A給接收質(zhì)量較差的客戶端重新發(fā)送語(yǔ)音包。
在上述實(shí)施方式中，接聽客戶端的接聽質(zhì)量是由發(fā)言客戶端根據(jù)來(lái)自接聽客戶端的RR報(bào)文統(tǒng)計(jì)出的。當(dāng)然，該統(tǒng)計(jì)操作也可以由PoC服務(wù)器來(lái)完成，即由PoC服務(wù)器根據(jù)來(lái)自接聽客戶端的RR報(bào)文統(tǒng)計(jì)接聽客戶端的接聽質(zhì)量，然后將其轉(zhuǎn)換為已設(shè)定好的接收質(zhì)量等級(jí)信息，將該接收質(zhì)量等級(jí)信息直接發(fā)送給發(fā)言客戶端。
例如，設(shè)定丟包率小于10％，抖動(dòng)小于1s時(shí)接收質(zhì)量?jī)?yōu)良；丟包率小于20％，抖動(dòng)小于2s時(shí)接收質(zhì)量為可接收；丟包率小于30％，抖動(dòng)小于3s時(shí)接收質(zhì)量較差；丟包率大于30％，抖動(dòng)大于3秒時(shí)接收質(zhì)量差。PoC服務(wù)器計(jì)算出各個(gè)發(fā)送RR報(bào)文的接聽客戶端的丟包率和抖動(dòng)時(shí)間后，將其轉(zhuǎn)換為相應(yīng)的接收質(zhì)量等級(jí)，然后直接給發(fā)言客戶端發(fā)送各個(gè)接聽客戶端的接收質(zhì)量等級(jí)信息，發(fā)言客戶端由此確認(rèn)各個(gè)接聽客戶端的接收效果。這樣，可以簡(jiǎn)化對(duì)客戶端的要求。
以上所述僅為本發(fā)明的較佳實(shí)施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種實(shí)現(xiàn)確認(rèn)PoC業(yè)務(wù)接收效果的方法，其特征在于，該方法包括以下步驟a、發(fā)言客戶端在發(fā)送報(bào)告消息SR中設(shè)置要求接聽客戶端發(fā)送接收?qǐng)?bào)告消息的標(biāo)識(shí)信息；b、發(fā)言客戶端在發(fā)言結(jié)束后請(qǐng)求PoC服務(wù)器將SR消息轉(zhuǎn)發(fā)給接聽客戶端；c、接聽客戶端接收到PoC服務(wù)器轉(zhuǎn)發(fā)的SR報(bào)文后，根據(jù)該消息中的接收?qǐng)?bào)告消息的標(biāo)識(shí)信息判斷自身是否需要發(fā)送RR報(bào)文，如果是，則向PoC服務(wù)器發(fā)送RR報(bào)文后，執(zhí)行步驟d，否則不做任何處理；d、根據(jù)接聽客戶端所發(fā)送的RR報(bào)文，發(fā)言客戶端確認(rèn)接聽客戶端的接收效果。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟c所述接聽客戶端判斷自身是否需要發(fā)送RR報(bào)文的方法包括以下步驟c1、根據(jù)SR報(bào)文中的接收?qǐng)?bào)告消息的標(biāo)識(shí)信息判斷是否要求所有的接聽客戶端發(fā)送RR報(bào)文，如果是，則向PoC服務(wù)器發(fā)送RR報(bào)文，否則執(zhí)行步驟c2；c2、判斷是否要求部分接聽客戶端發(fā)送RR報(bào)文，如果不是，則不需要自身發(fā)送RR報(bào)文，如果是，則進(jìn)一步判斷需要發(fā)送RR報(bào)文的用戶名中是否包含自身的用戶名，如果是，則向PoC服務(wù)器發(fā)送RR報(bào)文，否則不需要自身發(fā)送RR報(bào)文。
3.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟d所述根據(jù)接聽客戶端所發(fā)送的RR報(bào)文，發(fā)言客戶端確認(rèn)接聽客戶端接收效果的方法是發(fā)言客戶端接收到PoC服務(wù)器轉(zhuǎn)發(fā)的RR報(bào)文后，首先判斷所接收到的報(bào)文是否屬于本次發(fā)言的語(yǔ)音包，如果是，再根據(jù)接收到的RR報(bào)文計(jì)算出丟包率和到達(dá)間隔抖動(dòng)時(shí)間確認(rèn)各個(gè)發(fā)送RR報(bào)文的接聽客戶端的接收效果。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述PoC服務(wù)器給發(fā)言客戶端轉(zhuǎn)發(fā)RR報(bào)文的方法是PoC服務(wù)器接收到來(lái)自接聽客戶端的RR報(bào)文后，首先進(jìn)行緩存，然后再按照RTCP協(xié)議的定義，將所收集到的RR報(bào)文組裝成一個(gè)RR報(bào)文后，發(fā)送給發(fā)言客戶端。
5.根據(jù)權(quán)利要求4所述的方法，其特征在于，所述緩存的方式為PoC服務(wù)器每隔一段已設(shè)定的時(shí)間發(fā)送一次已組裝的RR報(bào)文，或者，每收集到已設(shè)定個(gè)數(shù)的RR報(bào)文，發(fā)送一次已組裝的RR報(bào)文。
6.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述發(fā)言客戶端判斷所接收到的報(bào)文是否屬于本次發(fā)言的語(yǔ)音包的方法是根據(jù)RR報(bào)文中的接收到的擴(kuò)展的最高序列號(hào)extended highest sequence number received字段判斷該RR報(bào)文是否屬于本次發(fā)言所產(chǎn)生的語(yǔ)音包的序號(hào)范圍之內(nèi)，如果是，則屬于本次發(fā)言所產(chǎn)生的語(yǔ)音包，否則，不屬于本次發(fā)言所產(chǎn)生的語(yǔ)音包。
7.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟d所述根據(jù)接聽客戶端所發(fā)送的RR報(bào)文，發(fā)言客戶端確認(rèn)接聽客戶端的接收效果的方法是由PoC服務(wù)器根據(jù)來(lái)自接聽客戶端的RR報(bào)文計(jì)算出各個(gè)發(fā)送RR報(bào)文的接聽客戶端的丟包率和到達(dá)間隔抖動(dòng)時(shí)間，并將已計(jì)算出的丟包率和到達(dá)間隔抖動(dòng)時(shí)間轉(zhuǎn)換為接收質(zhì)量等級(jí)發(fā)送給發(fā)言客戶端，由發(fā)言客戶端根據(jù)該接收質(zhì)量等級(jí)確認(rèn)各個(gè)發(fā)送RR報(bào)文的接聽客戶端的接收效果。
8.根據(jù)權(quán)利要求1所述的方法，其特征在于，該方法進(jìn)一步包括發(fā)言客戶端提示發(fā)言用戶向接收效果較差的接聽客戶端重新發(fā)送語(yǔ)音包。
全文摘要
本發(fā)明提供了一種實(shí)現(xiàn)確認(rèn)PoC業(yè)務(wù)接收效果的方法，其關(guān)鍵是由發(fā)言客戶端在SR中設(shè)置要求接聽客戶端發(fā)送接收?qǐng)?bào)告消息的標(biāo)識(shí)信息，發(fā)言客戶端在發(fā)言結(jié)束后請(qǐng)求PoC服務(wù)器將SR消息轉(zhuǎn)發(fā)給接聽客戶端；接聽客戶端接收到PoC服務(wù)器轉(zhuǎn)發(fā)的SR報(bào)文，根據(jù)該報(bào)文中的接收?qǐng)?bào)告消息的標(biāo)識(shí)信息判斷出自身需要發(fā)送RR報(bào)文后，再向PoC服務(wù)器發(fā)送RR報(bào)文，根據(jù)接聽客戶端所發(fā)送的RR報(bào)文，發(fā)言客戶端確認(rèn)接聽客戶端的接收效果。應(yīng)用本發(fā)明實(shí)現(xiàn)了發(fā)言客戶端迅速準(zhǔn)確地確認(rèn)接聽客戶端的接聽效果，而且避免了由于很多用戶搶占發(fā)言權(quán)而對(duì)系統(tǒng)造成的沖擊。本發(fā)明能夠滿足具有較高可靠性要求的應(yīng)用業(yè)務(wù)。同時(shí)運(yùn)營(yíng)商還可以對(duì)此項(xiàng)服務(wù)進(jìn)行計(jì)費(fèi)，以增加其收入。
文檔編號(hào)H04W4/10GK1728839SQ200410054669
公開日2006年2月1日 申請(qǐng)日期2004年7月27日 優(yōu)先權(quán)日2004年7月27日
發(fā)明者羅龍 申請(qǐng)人:華為技術(shù)有限公司