專利名稱：一種群組會話中的媒體傳送方法和參與群組會話的客戶端的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及移動通信領(lǐng)域，尤其涉及一種群組會話中的媒體傳送方法和 參與群組會話的客戶端。
背景技術(shù)：
無線一鍵通系統(tǒng)(Push-to-Talk Over Cellular,簡稱"PoC")是開》文移動 聯(lián)盟(Open Mobile Alliance,簡稱"OMA")定義的在分組網(wǎng)絡(luò)上實現(xiàn)的PTT (Push to Talk)業(yè)務(wù)，采用分組語音(Voice over IP,簡稱"VoIP，，)技術(shù)以 及半雙工的方式，低成本、高效率地滿足客戶端的實時通信需求。通過這種 業(yè)務(wù)，客戶端可以向單個客戶端或群組發(fā)起PoC會話，實現(xiàn)一對一或一對多 的會話方式。
OMA是基于互聯(lián)網(wǎng)工程任務(wù)組(Internet Engineering Task Force,簡稱 "IETF")所定義的會話發(fā)起協(xié)議(Session Initiation Protocol,簡稱"SIP")和 實時傳輸協(xié)議(Real-Time Transfer Protocol,簡稱"RTP")來定義PoC。隨著 PoC業(yè)務(wù)的發(fā)展，在PoC2.0中出現(xiàn)了新的媒體內(nèi)容，除了PoC1.0中支持的 語音外，這些新的媒體內(nèi)容還包括視頻、圖片、文件等。在OMA定義的使 能部件中，IM (Instant Message)也涉及在群組中傳送文件的問題。PoC和IM 采用了相同的傳輸文件的協(xié);義MSRP( Message Session Relay Protocol:消息中 繼協(xié)議)，而語音和視頻信息則采用RTP協(xié)議傳送。
在PoC系統(tǒng)中，通常在發(fā)起會話時，協(xié)商好各種媒體(包括語音、視頻、 文件傳送等)參數(shù)，包括媒體類型、IP地址、端口號、編碼方式等等。在會 話過程中，客戶端申請發(fā)言權(quán)即傳送文件的請求，獲得發(fā)言權(quán)之后即可以發(fā) 言即傳送文件。其中，申請發(fā)言權(quán)并不是必須的，各系統(tǒng)可以選擇性的實現(xiàn)
這個功能。在需要申請發(fā)言權(quán)的情況下，客戶端先向服務(wù)器提出傳送文件請
求，獲得許可后才可以傳送文件；在不需要申請發(fā)送權(quán)限的情況下，客戶端 可以直接傳送文件，即不需要服務(wù)器獲得許可。在群組會話過程中，客戶端 獲得傳送文件許可之后即可傳送文件，文件傳送送完畢后傳送文件的會話并
送文件。
目前，參與PoC群組會話的群組成員傳送媒體的方法如圖l所示，具體 流程如下
步驟IOI、 PoC群組會話建立，并協(xié)商好媒體參數(shù)；
步驟102—103、主叫客戶端向控制功能服務(wù)器發(fā)送傳送媒體的請求,該 請求消息中包含了將要發(fā)送的媒體類型；
步驟104、控制功能服務(wù)器對收到的請求進行發(fā)言權(quán)判斷；
步驟105—106、若主叫客戶端的傳送媒體的請求成功,控制功能服務(wù)器 向主叫客戶端發(fā)送傳送媒體確認消息，允許傳送媒體；
步驟107—108、控制功能服務(wù)器向被叫客戶端發(fā)送接收媒體的消息。當 然，步驟105—106與107—108之間沒有嚴格的時間順序，控制功能服務(wù)器 可以同時向主叫客戶端和被叫客戶端分別發(fā)送消息，也可以分先后發(fā)送。
步驟109—112、主叫客戶端向被叫客戶端傳送媒體A。
從上可以看出，在PoC系統(tǒng)中是先協(xié)商會話媒體參數(shù)，再傳送會話內(nèi)容， 會話過程中，可以多次傳送，但一旦傳送，用戶必須接收會話中的信息。實 際上，用戶參與群組會話并不代表用戶就愿意接收所有會話中的文件。用戶 存在拒絕接收某特定用戶發(fā)送過來的某個特定內(nèi)容的需求，如用戶A想發(fā)送 給用戶B —首歌，用戶B聽過這首歌，他于是拒絕接收。另外，因為一個 SIP會話中包含了多種媒體，使得一個語音RTP會話可以和多個文件傳送的
MSRP會話并存，在物理資源一定的情況下，如不對MSRP的會話個數(shù)進行 限制，必然會導(dǎo)致語音會話質(zhì)量大幅度下降，從而影響通話質(zhì)量。因此，現(xiàn) 有技術(shù)中存在以下缺點較差的用戶體驗和網(wǎng)絡(luò)資源的浪費。

發(fā)明內(nèi)容
本發(fā)前提供了 一種群組會話中媒體的傳送方法，以使在群組會話過程中 傳送媒體時用戶有較好的體驗。該方法包括以下步驟A、服務(wù)器收到主叫 客戶端發(fā)送傳送媒體的請求消息；B、服務(wù)器根據(jù)所述傳送媒體的請求消息 判斷需要被叫客戶端確認，并向參與群組會話的被叫客戶端發(fā)送傳送媒體的 請求消息；C、被叫客戶端確認，服務(wù)器向已確認的被叫客戶端傳送所述媒 體。
優(yōu)選的，步驟B之前還應(yīng)執(zhí)行服務(wù)器獲取所述請求消息中的信息，并 利用所述信息與服務(wù)器存儲的策略進行比較，判斷需所述請求需要被叫客戶 端確認。
優(yōu)選的，步驟A中所述請求消息攜帶媒體的描述信息和/或主叫客戶端標 識和/或群組會話標識，步驟B中服務(wù)器根據(jù)所述描述信息或主叫客戶端標識 或群組會話標識判斷所述請求需要參與群組會話的被叫客戶端確認。
優(yōu)選的，服務(wù)器預(yù)定義群組會話中允許傳送媒體的個數(shù)和正在傳送的媒 體的個數(shù)，步驟B之前還應(yīng)執(zhí)行如下步驟Bl:服務(wù)器判斷正在傳送的媒體 的個數(shù)是否大于群組會話中允許傳送媒體的個數(shù)，如果是，執(zhí)行步驟B2，否 則執(zhí)行步驟B; B2、服務(wù)器緩存所述請求消息，并且當群組會話中傳送的媒 體的個數(shù)值小于預(yù)定義值時執(zhí)行步驟B。
優(yōu)選的，服務(wù)器預(yù)設(shè)首次收到被叫客戶端確認消息的時間，步驟C之前 還應(yīng)執(zhí)行服務(wù)器判斷在其預(yù)設(shè)的時間內(nèi)首次收到被叫客戶端的確認消息。
優(yōu)選的，步驟C中被叫客戶端回復(fù)確認消息后，執(zhí)行以下步驟C 1、服務(wù) 器向主叫客戶端發(fā)送傳送媒體的確認響應(yīng)消息；C2、主叫客戶端向服務(wù)器傳送媒體；C3、服務(wù)器向回復(fù)確認消息的被叫客戶端傳送所述媒體。
優(yōu)選的，步驟C3包括C31、服務(wù)器將所述媒體緩存；C32、服務(wù)器將 緩存的媒體傳送給向服務(wù)器回復(fù)確認消息的被叫客戶端。
優(yōu)選的，服務(wù)器設(shè)置媒體的緩存時間，服務(wù)器在所述緩存時間內(nèi)收到被 叫客戶端的確認消息后，向所述被叫客戶端傳送所述媒體。
優(yōu)選的，該方法還包括如下步驟服務(wù)器記錄被叫客戶端是否接收所述 媒體，并將結(jié)果傳送給主叫客戶端。
此外，本發(fā)明還提供一種參與群組會話的客戶端，其特征在于該客戶端 包括輸入端、處理單元、輸出端；所述輸入端用于接收服務(wù)器發(fā)送的傳送媒 體的請求消息和根據(jù)服務(wù)器發(fā)送的接收媒體的指示消息接收服務(wù)器傳送的媒 體；所述處理單元用于根據(jù)服務(wù)器發(fā)送的傳送媒體的請求消息判斷是否接收 媒體；所述輸出端用于根據(jù)處理單元的判斷結(jié)果向服務(wù)器發(fā)送確認接收消息 或拒絕接收消息。
優(yōu)選的，所述傳送媒體的請求消息包括主叫客戶端標識和/或群組會話標 識和/或媒體描述信息，所述處理單元存儲是否接收媒體的策略，并根據(jù)請求 消息中的主叫客戶端標識和/或群組會話標識和/或々某體描述信息與所述策略 判斷是否接收媒體。
優(yōu)選的，所述輸出端還用于向服務(wù)器發(fā)送傳送媒體的請求消息；所述輸 入端接收到服務(wù)器發(fā)送的確認消息后，輸出端向服務(wù)器傳送媒體。 由以上方案可以看出，本發(fā)明的有益效果如下
1) 當服務(wù)器判斷主叫客戶端需要傳送的媒體需被叫客戶端確認是否 接收時，由被叫客戶端確認是否接收，使被叫客戶端只接收所確定的媒體， 增加被叫客戶端的用戶體驗；以及服務(wù)器只向需要接收的被叫客戶端傳送所 述Jf某體，從而可以節(jié)省網(wǎng)絡(luò)資源。
2) 服務(wù)器限制了群組會話中傳送媒體的個數(shù)，當正在傳送的媒體的數(shù) 值大于群組會話中傳送媒體的個數(shù)，則拒絕主叫客戶端傳送媒體的請求或?qū)?此請求緩存，從而保證群組會話的質(zhì)量。


1. 圖1為現(xiàn)有技術(shù)中傳送媒體的流程2. 圖2所示為PoC的架構(gòu)圖。
3. 圖3為本發(fā)明提供的傳送媒體的流程4. 圖4為本發(fā)明提供的群組會話中傳送媒體的具體實施例的流程5. 圖5為本發(fā)明提供的被叫客戶端接收媒體的具體實施例的流程6. 圖6為本發(fā)明提供的傳送媒體的系統(tǒng)示意圖
具體實施例方式
下面結(jié)合附圖和具體實施例對本發(fā)明再作進一步詳細的說明。 圖2所示為PoC的架構(gòu)圖。
從PoC架構(gòu)圖中可以看出，PoC功能部件主要包括PoC客戶端、PoC服 務(wù)器、XML文檔管理客戶端、PoCXML文檔管理服務(wù)器。其中PoC服務(wù)器 可按邏輯劃分為控制功能服務(wù)器和參與功能服務(wù)器，當然這兩種邏輯功能服 務(wù)器也可以同時由一個物理PoC服務(wù)器來執(zhí)行。
在本發(fā)明中，主要涉及到了 PoC客戶端與PoC服務(wù)器間的媒體及媒體控 制信令流，即媒體發(fā)送請求和媒體內(nèi)容的傳送以及應(yīng)答消息的傳送，這些過 程均通過客戶端和服務(wù)器利用PoC-3接口交互完成。
當PoC服務(wù)器執(zhí)行控制功能時，則該服務(wù)器為控制功能服務(wù)器，媒體發(fā) 送請求的判斷和媒體內(nèi)容的緩存均在執(zhí)行控制功能的控制服務(wù)器中完成；當 PoC服務(wù)器執(zhí)行參與功能時，則該服務(wù)器為參與功能服務(wù)器，本發(fā)明中的參
與功能服務(wù)器主要是用來中轉(zhuǎn)媒體和媒體控制信令。
如圖3所示，本發(fā)明所提供在群組會話中的傳送媒體的流程如下
步驟301、主叫客戶端向服務(wù)器發(fā)送發(fā)言權(quán)請求消息，該消息中還攜帶 所請求的具體媒體類型及即將傳送的媒體的描述信息。
步驟302、服務(wù)器收到主叫客戶端發(fā)送的發(fā)言權(quán)請求消息后，根據(jù)請求 消息中的媒體描述信息，判斷是否需要被叫客戶端的確認，如果需要被叫客 戶端確i人則執(zhí)4亍步驟303;否則直接執(zhí)行步驟305;
步驟303、服務(wù)器向被叫客戶端發(fā)送攜帶媒體的描述信息的媒體傳送的 請求消息。
步驟304、被叫客戶端根據(jù)收到的請求消息，判斷接收主叫客戶端將要 傳送的文件，并向客戶端返回確i人消息；
步驟305、服務(wù)器向主叫客戶端發(fā)送發(fā)言權(quán)確認消息，并向被叫客戶端 發(fā)送接收媒體的指示消息；
步驟306、主叫客戶端向被叫客戶端傳送媒體。
如圖4所示，本發(fā)明提供的在群組會話中傳送媒體的具體實施例，其中 群組會話建立，且參與群緩會話的群組成員(即主被叫)可用，其具體的流 程如下
步驟401—"402、主叫客戶端向控制功能服務(wù)器發(fā)送媒體請求消息，該消 息中攜帶將要傳送的媒體的描述信息(如文件的大小、類型等)。
步驟403，控制功能服務(wù)器判斷收到主叫客戶端的請求消息后的正在傳 送的媒體的個數(shù)值是否大于控制功能服務(wù)器的預(yù)定義的群組會話中允許的媒 體傳送的個數(shù)值，如果是，順序執(zhí)行步驟404~~405或執(zhí)行步驟406,否則直 接執(zhí)行步驟407;
其中，控制功能服務(wù)器記錄了正在傳送的媒體的個數(shù)值(簡稱第一數(shù)值)
以及群組會話中允許傳送的媒體的個數(shù)的數(shù)值(簡稱第二數(shù)值)，當控制功 能服務(wù)器收到主叫客戶端發(fā)送的媒體發(fā)言權(quán)請求消息時，便將第一數(shù)值加1， 而如果一個媒體傳送完畢，控制功能服務(wù)器便將第一數(shù)值減1。并且，控制 功能服務(wù)器預(yù)定義了當?shù)谝粩?shù)值大于第二數(shù)值時的策略，因此當?shù)谝粩?shù)值大 于第二數(shù)值時，控制功能服務(wù)器根據(jù)其自身是否支持媒體發(fā)送請求消息的緩
存功能，如果控制功能服務(wù)器支持請求消息的緩存，則執(zhí)行步驟404~405; 否則執(zhí)行步驟406。
步驟404—405，控制功能服務(wù)器向主叫客戶端返回請求失敗的消息，即 不允許主叫客戶端傳送媒體，并結(jié)束流程。
步驟406、控制功能服務(wù)器將主叫客戶端的請求消息緩存，并等到群組 會話中傳送的媒體的個數(shù)小于預(yù)定義值時，執(zhí)行步驟407。
步驟407、控制功能服務(wù)器設(shè)置是否將媒體傳送請求發(fā)送給被叫客戶端 確認的策略(例如對文件和圖片等需要被叫確認而對于語音則不需要被叫確 認等)，并根據(jù)主叫的媒體發(fā)送請求消息進行判斷l(xiāng).控制服務(wù)器獲取主叫客 戶端的媒體發(fā)送請求消息中的用戶ID值、會話ID值、媒體類型等信息；2. 控制服務(wù)器將從請求消息中獲取的信息與控制服務(wù)器策略相比較；3.控制服 務(wù)器根據(jù)比較結(jié)果進行判斷。判斷是否將該請求消息發(fā)送給被叫客戶端確認， 如果是，執(zhí)行步驟408;否則直接執(zhí)行步驟410;
步驟408、控制功能服務(wù)器向參與群組會話的其它客戶端(被叫客戶端) 傳送媒體請求消息。
其中，控制功能服務(wù)器預(yù)設(shè)收到被叫客戶端首次回復(fù)同意接收所述媒體
的確認消息的時間，以及控制功能服務(wù)器設(shè)置接收主叫客戶端傳送的媒體后
緩存所述媒體的時間并且為了描述方便，將參與群組會話的接收傳送媒體請
求消息的客戶端統(tǒng)稱被叫客戶端，而在控制功能服務(wù)器預(yù)設(shè)的首次收到被叫 客戶端回復(fù)同意接收所述媒體的確認消息的時間范圍內(nèi)收到所述確認消息的
被叫客戶端稱為第一類被叫客戶端。
在第 一類被叫客戶端回復(fù)確認消息后，在服務(wù)器緩存主叫客戶端傳送的 所述媒體的時間范圍內(nèi)回復(fù)確認消息的客戶端統(tǒng)稱為第二類被叫客戶端。
超過服務(wù)器緩存主叫客戶端傳送的所述媒體的時間范圍向服務(wù)器回復(fù)確 認消息的被叫客戶端統(tǒng)稱為第三類被叫客戶端。
在控制功能服務(wù)器預(yù)設(shè)的首次收到被叫客戶端回復(fù)同意接收所述媒體的 確認消息的時間范圍，回復(fù)拒絕接收媒體消息的客戶端稱為第四類被叫客戶
下面將針對四種不同類型的被叫客戶端的流程分別介紹。
一 、控制功能服務(wù)器在預(yù)設(shè)時間范圍內(nèi)首次收到被叫客戶端的確認消息
后，執(zhí)行以下步驟
步驟409、第一類被叫客戶端判斷接收該消息中的媒體，并向控制功能 服務(wù)器發(fā)送確認響應(yīng)消息；
步驟410、控制功能服務(wù)器預(yù)設(shè)一個時間值，在此時間范圍內(nèi)(從控制 功能服務(wù)器向被叫客戶端傳送媒體請求消息開始計算)，控制功能服務(wù)器判 斷收到第 一類被叫客戶端的確認響應(yīng)消息；
步驟411一412、控制功能服務(wù)器向主叫客戶端發(fā)送媒體發(fā)言權(quán)確認響應(yīng) 消息，即同意主叫客戶端傳送多媒體；
步驟413、控制功能服務(wù)器向第一類被叫客戶端發(fā)送接收媒體發(fā)言權(quán)的 指示消息；當然，該消息也可以與步驟311同時進行；
步驟414-~415、主叫客戶端向控制功能服務(wù)器傳送媒體。
步驟416、控制功能服務(wù)器將主叫客戶端發(fā)送過來的媒體緩存，并且設(shè) 定緩存時間，對于超時緩存的媒體將會被丟棄。
步驟417 、控制功能服務(wù)器將緩存的媒體分發(fā)給向控制功能服務(wù)器發(fā)送 給第一類被叫客戶端，并結(jié)束流程。
二 、服務(wù)器沒有在預(yù)設(shè)時間內(nèi)收到被叫客戶端的確認消息或只收到第四 類被叫客戶端的拒絕消息，執(zhí)行以下步驟
步驟409，、第四類被叫客戶端判斷拒絕接收該消息中的媒體，并向控
制功能服務(wù)器發(fā)送拒絕接收媒體的消息；
當然，被叫客戶端并不是必須要向控制功能服務(wù)器回復(fù)消息，如果客戶 端不愿接收所述媒體以及沒有及時獲知控制功能服務(wù)器發(fā)送的媒體發(fā)言權(quán)請 求消息，還可以不作任何動作。
步驟410'、控制功能服務(wù)器預(yù)設(shè)一個時間值，在此時間范圍內(nèi)(從控制 功能服務(wù)器向被叫客戶端發(fā)送媒體發(fā)言權(quán)請求消息開始計算)，控制功能服 務(wù)器判斷沒有收到被叫客戶端的確認響應(yīng)消息，可以是沒有收到被叫客戶端 的任何消息，或只收到第四類被叫客戶端的拒絕接收的消息；
步驟411，~412，、控制功能服務(wù)器向主叫客戶端返回發(fā)言權(quán)請求失敗的 消息,并結(jié)束該流程。在該流程中，服務(wù)器向主叫客戶端回復(fù)請求失敗的消息， 主叫客戶端就不向服務(wù)器發(fā)送媒體，從而節(jié)省網(wǎng)絡(luò)資源。
三、 控制功能服務(wù)器在預(yù)設(shè)的首次收到被叫客戶端回復(fù)的確認消息時間 內(nèi)收到第一類被叫客戶端的確認消息，并在其設(shè)置的緩存主叫客戶端傳送的 媒體的時間范圍內(nèi)收到第二類被叫客戶端回復(fù)的同意接收所述媒體的確認消 息，執(zhí)行如下步驟
步驟409"、第二類被叫客戶端向控制功能服務(wù)器回復(fù)確認消息，表示同 意接收所述媒體；
步驟410"，控制功能服務(wù)器判斷該確認響應(yīng)消息在控制功能服務(wù)器緩存 媒體的時間范圍內(nèi)。
步驟411"、控制功能服務(wù)器向第二類被叫客戶端發(fā)送接收媒體的指示消
息；
步驟412"、控制功能服務(wù)器向第二類被叫客戶端傳送所緩存的媒體并結(jié) 束流程。
四、 控制功能服務(wù)器在預(yù)設(shè)的首次收到被叫客戶端回復(fù)的確認消息時間 內(nèi)收到第 一類被叫客戶端的確認消息，但超過了其設(shè)置的緩存主叫客戶端傳
送的媒體的時間范圍而收到了第三類被叫客戶端回復(fù)的同意接收所述媒體的
確認消息，執(zhí)行如下步驟
409"，，第三類被叫客戶端向控制功能服務(wù)器回復(fù)確認消息，表示同意 接收所述媒體；
步驟410"，，控制功能服務(wù)器判斷該確認響應(yīng)消息超過了控制功能服務(wù) 器緩存媒體的時間范圍。
步驟411"，，控制功能服務(wù)器向第三類被叫客戶端發(fā)送時間超時的指示 信息，或不執(zhí)行任何動作，不再向該被叫客戶端發(fā)送媒體，并結(jié)束流程。
步驟418,當媒體傳送流程結(jié)束，控制服務(wù)器記錄記錄每個被叫客戶端 的媒體接收情況,例如被叫是否收到該媒體。
步驟419"~420, PoC控制服務(wù)器將記錄被叫客戶端接收情況的報告發(fā)送 給主叫客戶端。
當然，圖4所示幾種類型的客戶端對于是否接收媒體的情況并非在同一 會話中同時出現(xiàn)。
如圖5所示，本發(fā)明提供的被叫客戶端接收主叫客戶端傳送的媒體的具 體實施例的流程如下
步驟501—504、控制功能服務(wù)器收到主叫客戶端發(fā)送的傳送媒體的請求 消息，并依據(jù)該消息判斷需要經(jīng)過參與群組會話的所有其它群組成員確認后， 向參與群組會話的所有其它成員的客戶端(即被叫客戶端)發(fā)送傳送媒體 的請求消息；
步驟505—506、被叫客戶端A (即第一類被叫客戶端)同意接收請求消 息中描述的媒體，并向控制功能服務(wù)器發(fā)送確認響應(yīng)消息,該確認消息可由用 戶選擇發(fā)出也可以通過客戶端設(shè)置自動發(fā)出；或者，
步驟506'、第一類被叫客戶端的參與功能服務(wù)器(即被叫參與功能服務(wù) 器)根據(jù)用戶預(yù)先設(shè)置的策略對控制功能服務(wù)器發(fā)送來的請求消息進行判斷， 并自動返回接收該々某體的應(yīng)答消息；
步驟507—508、控制功能服務(wù)器向第一類被叫客戶端發(fā)送接收媒體的指 示消息；
步驟509、控制功能服務(wù)器將主叫客戶端發(fā)送來的媒體緩存起來。 步驟510—511、控制功能服務(wù)器向第一類被叫客戶端傳送媒體。 步驟512—513、被叫客戶端X(第二類被叫客戶端)同意接收請求消息 中描述的媒體，并向控制功能服務(wù)器發(fā)送確認響應(yīng)消息，該確認消息可由用戶 選擇發(fā)出也可以通過客戶端設(shè)置自動發(fā)出；(當然，此步驟可與步驟510—511 同時進行)。
步驟514—515、控制功能服務(wù)器向第二類被叫客戶端發(fā)送接收媒體的指 示消息；
步驟516—517、控制功能服務(wù)器向被叫客戶端X傳送媒體，并結(jié)束流程。 如果被叫客戶端X超過控制功能服務(wù)器緩存媒體的時間向控制功能服務(wù)
器回復(fù)確認消息，則被叫客戶端X擔任前述的第三類被叫客戶端的角色，并
執(zhí)4亍如下流程
步驟514，一515'、因為控制服務(wù)器收到被叫客戶端X (即第三類被叫客 戶端)發(fā)來的接收媒體確認消息已經(jīng)超時，則控制服務(wù)器向被叫客戶端X返 回確認超時指示消息或不執(zhí)行任何動作，并且不再向被叫客戶端X發(fā)送媒體， 結(jié)束流程。
如圖6所示，本發(fā)明提供的一種傳送媒體的系統(tǒng)包括客戶端與服務(wù)器。 所述客戶端包括輸入端、輸出端和處理單元；
所述輸入端用于接收服務(wù)器發(fā)送的傳送媒體的請求消息和根據(jù)服務(wù)器發(fā) 送的接收媒體的指示消息接收服務(wù)器傳送的媒體；其中，所述傳送媒體的請 求消息包括主叫客戶端標識和/或群組會話標識和/或i某體描述信息；
所述處理單元所述處理單元存儲是否接收媒體的策略，并根據(jù)請求消息 中的主叫客戶端標識和/或群組會話標識和/或媒體描述信息與所述策略判斷 是否接收媒體； 拒絕接收消息。
如杲客戶端承擔的是主叫的角色，所述輸出端還用于向服務(wù)器發(fā)送傳送 媒體的請求消息；所述輸入端接收到服務(wù)器發(fā)送的確認消息后，輸出端向服 務(wù)器傳送媒體。
從以上方案可以看出，本發(fā)明通過當服務(wù)器判斷主叫客戶端需要傳送的 媒體需被叫客戶端確認是否接收時，由被叫客戶端確認是否接收，使第被叫
客戶端只接收所確定的々某體，增加被叫客戶端的用戶體驗；以及服務(wù)器只向 需要接收的被叫客戶端傳送所述媒體，從而可以節(jié)省網(wǎng)絡(luò)資源。
雖然通過參照本發(fā)明的某些優(yōu)選實施方式，已經(jīng)對本發(fā)明進行了圖示和 描述，但本領(lǐng)域的普通技術(shù)人員應(yīng)該明白，可以在形式上和細節(jié)上對其作各 種改變，而不偏離本發(fā)明的精神和范圍。
權(quán)利要求
1.一種群組會話中媒體傳送方法，其特征在于該方法包括如下步驟A、服務(wù)器收到主叫客戶端發(fā)送傳送媒體的請求消息；B、服務(wù)器根據(jù)所述傳送媒體的請求消息判斷需要被叫客戶端確認，并向參與群組會話的被叫客戶端發(fā)送傳送媒體的請求消息；C、被叫客戶端確認，服務(wù)器向已確認的被叫客戶端傳送所述媒體。
2. 如權(quán)利要求1所述的群組會話中媒體傳送方法，其特征在于步 還應(yīng)執(zhí)行服務(wù)器獲取所述請求消息中的信息，并利用所述信息與服務(wù)器存 儲的策略進行比較，判斷需所述請求需要被叫客戶端確認。
3. 如權(quán)利要求1所述的群組會話中媒體傳送方法，其特征在于步驟A中 所述請求消息攜帶媒體的描述信息和/或主叫客戶端標識和/或群組會話標 識，步驟B中服務(wù)器根據(jù)所述描述信息或主叫客戶端標識或群組會話標識判 斷所述請求需要參與群組會話的被叫客戶端確認。
4. 如權(quán)利要求1所述的群組會話中媒體傳送方法，其特征在于服務(wù)器預(yù) 還應(yīng)執(zhí)行如下步驟個數(shù)，如果是，執(zhí)行步驟B2，否則執(zhí)行步驟B;B2、服務(wù)器緩存所述請求消息，并且當群組會話中傳送的媒體的個數(shù)值小于 預(yù)定義值時執(zhí)行步驟B。
5. 如權(quán)利要求1所述的群組會話中媒體傳送方法，其特征在于服務(wù)器預(yù) 設(shè)首次收到被叫客戶端確認消息的時間，步驟C之前還應(yīng)執(zhí)行服務(wù)器判斷在其預(yù)設(shè)的時間內(nèi)首次收到被叫客戶端的確認消息。
6. 如權(quán)利要求1所述的群組會話中媒體傳送方法，其特征在于步驟C中被叫客戶端回復(fù)確i人消息后，執(zhí)4亍以下步驟Cl、服務(wù)器向主叫客戶端發(fā)送傳送媒體的確認響應(yīng)消息；C2、主叫客戶端向服務(wù)器傳送媒體；C3 、服務(wù)器向回復(fù)確認消息的被叫客戶端傳送所述媒體。
7. 如權(quán)利要求6所述的群組會話中媒體的傳送方法，其特征在于步驟C3 包括C31、服務(wù)器將所述媒體緩存；C32、服務(wù)器將緩存的媒體傳送給向服務(wù)器回復(fù)確認消息的被叫客戶端。
8. 如權(quán)利要求7所述的群組會話中媒體的傳送方法，其特征在于服務(wù)器設(shè) 置媒體的緩存時間，服務(wù)器在所述緩存時間內(nèi)收到被叫客戶端的確認消息 后，向所述被叫客戶端傳送所述媒體。
9. 如權(quán)利要求1所述的群組會話中媒體的傳送方法，其特征在于該方法還 包括如下步驟服務(wù)器記錄被叫客戶端是否接收所述媒體，并將結(jié)果傳送給 主叫客戶端。
10. —種參與群組會話的客戶端，其特征在于該客戶端包括輸入端、處理單 元、輸出端；所述輸入端用于接收服務(wù)器發(fā)送的傳送媒體的請求消息和根據(jù)服務(wù)器發(fā)送 的接收媒體的指示消息接收服務(wù)器傳送的媒體；所述處理單元用于根據(jù)服務(wù)器發(fā)送的傳送媒體的請求消息判斷是否接收媒 體；絕接收消息。
11. 如權(quán)利要求10所述的參與群組會話的客戶端，其特征在于所述傳送媒體的請求消息包括主叫客戶端標識和/或群組會話標識和/或媒體描述信息， 所述處理單元存儲是否接收媒體的策略，并根據(jù)請求消息中的主叫客戶端標 識和/或群組會話標識和/或媒體描述信息與所述策略判斷是否接收媒體。
12.如權(quán)利要求IO所述的參與群組會話的客戶端，其特征在于 所述輸出端還用于向服務(wù)器發(fā)送傳送媒體的請求消息； 所述輸入端接收到服務(wù)器發(fā)送的確認消息后，輸出端向服務(wù)器傳送媒體。
全文摘要
本發(fā)明提供了一種群組會話中的媒體傳送方法和參與群組會話的客戶端。所述方法包括服務(wù)器收到主叫客戶端發(fā)送傳送媒體的請求消息；服務(wù)器根據(jù)所述傳送媒體的請求消息判斷需要被叫客戶端確認，并向參與群組會話的被叫客戶端發(fā)送傳送媒體的請求消息；被叫客戶端確認，服務(wù)器向已確認的被叫客戶端傳送所述媒體。所述客戶端包括用于接收服務(wù)器發(fā)送的傳送媒體的請求消息和根據(jù)服務(wù)器發(fā)送的接收媒體的指示消息接收服務(wù)器傳送的媒體的輸入端；用于根據(jù)服務(wù)器發(fā)送的傳送媒體的請求消息判斷是否接收媒體的處理單元；用于根據(jù)處理單元的判斷結(jié)果向服務(wù)器發(fā)送確認接收消息或拒絕接收消息的輸出端。利用本發(fā)明，可以增加用戶體驗以及節(jié)省網(wǎng)絡(luò)資源。
文檔編號H04M3/42GK101111006SQ20061006168
公開日2008年1月23日 申請日期2006年7月17日 優(yōu)先權(quán)日2006年7月17日
發(fā)明者伍旭剛, 張生庭, 林 李 申請人:華為技術(shù)有限公司