專利名稱：在會議系統(tǒng)中向終端發(fā)送多媒體消息的方法、系統(tǒng)和設(shè)備的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及多媒體會議技術(shù)，特別涉及一種在基于會話初始協(xié)議(SIP)的會議系統(tǒng)中向終端發(fā)送多媒體消息的方法、系統(tǒng)和設(shè)備。
背景技術(shù)：
在當(dāng)前的基于SIP的多媒體會議系統(tǒng)(以下簡稱為會議系統(tǒng))中，每一個參會者在發(fā)送自己的多媒體消息時，都希望該消息能夠被其他參會者正確地接 收，并通過恰當(dāng)?shù)姆绞竭M行顯示或播放。但是，由于不同參會者的終端與會議 中心的協(xié)商能力存在差異，所以很可能會造成其他參會者終端不能正常接收來 自發(fā)送方終端的多媒體消息，從而降低會議質(zhì)量。每個參會者在新加入會議系統(tǒng)時，會議中心會首先與參會者的終端進行能 力協(xié)商，協(xié)商內(nèi)容包括會議中心以及參會者終端所支持的媒體類型、消息大小 以及消息長度等，會議中心在協(xié)商完成后會記錄下參會者終端的協(xié)商能力信息。 這樣，在會議進行過程中，當(dāng)某個參會者(發(fā)送方)要向其他某個參會者(接 收方)發(fā)送多媒體消息時，會議中心會首先檢查接收方終端是否支持發(fā)送方終 端所發(fā)送的多媒體消息，比如是否支持所發(fā)送的多媒體類型，如果支持，則按正常流程將該多々某體消息發(fā)送給接收方終端；如果不支持，則會議中心將不會 將該多媒體消息轉(zhuǎn)發(fā)給接收方終端，當(dāng)然接收方終端也就無法接收到該多媒體 消息，從而造成會話失敗。目前多媒體短消息業(yè)務(wù)(MMS )中提出了 一種針對在MMS業(yè)務(wù)中存在的 上述類似問題的解決方案，圖1為MMS中的點到點業(yè)務(wù)實現(xiàn)流程圖，如圖1 所示，包括以下步驟步驟101 ~ 102:發(fā)送方終端向多媒體短消息業(yè)務(wù)中心(MMSC)發(fā)送多媒體短消息提交請求(MMl_Submit.REQ)消息，該MM1—Submit.REQ消息中攜 帶有發(fā)送方終端要發(fā)送給接收方終端的多媒體短消息內(nèi)容；MMSC成功接收該 MM l一Submit.REQ消息后，向發(fā)送方終端回送多+某體短消息提交響應(yīng)(MM1—Submit.RES)消息。步驟103 ~ 104: MMSC向接收方終端發(fā)送多媒體短消息通知請求(MM1—Notification.REQ)消息，通知接收方終端在MMSC中有一個多媒體短 消息需要其接收；接收方終端接收到MMl_Notification.REQ消息后，向MMSC 回送多4某體短消息通知響應(yīng)(MM1—Notification.RES)消息。步驟105 ~ 106:接收方終端向MMSC發(fā)送多媒體短消息提取請求(MMl一Retrieve.REQ )消息，請求提取發(fā)送方終端發(fā)送來的多媒體短消息； MMSC向接收方終端回送多媒體短消息提取響應(yīng)(MM1—Retrieve.RES )消息， MM1—Retrieve.RES消息中攜帶有發(fā)送方終端發(fā)送給接收方終端的多媒體短消 息。步驟107:接收方終端接收到上述多媒體短消息后，向MMSC回送多媒體短 消息確認請求(MMl_Acknowledge.REQ)消息。上述過程中，若接收方終端在預(yù)定時間內(nèi)未提取發(fā)送方終端發(fā)送來的多媒 體短消息，則MMSC將該多々某體短消息進行轉(zhuǎn)存處理，而且當(dāng)接收方終端不支 持該多媒體短消息時，MMSC將為接收方終端提供內(nèi)容適配能力，以使得接收 方終端能夠正確接收并處理該多i某體短消息。但是，上述方法雖然應(yīng)用在MMS中可以達到較好的效果，在多媒體會議 系統(tǒng)中卻并不適用。首先來說，MMSC將接收自發(fā)送方終端的多媒體短消息存 儲到預(yù)定時間，若仍未接收到接收方終端發(fā)送來的提取請求，才會將該多媒體 短消息進行轉(zhuǎn)存就是不適合于會議系統(tǒng)的，因為會議系統(tǒng)是一個實時處理信息 的過程；其次，MMS中內(nèi)容適配能力為終端實際具備的能力，在適配不成功時， MMS會將原始多媒體消息發(fā)送給接收方終端或直接將該原始多媒體消息刪除， 但SIP會議系統(tǒng)中的內(nèi)容適配能力是由會議中心服務(wù)器與參會者終端協(xié)商的， 其不具備上述功能，不能按照自己的策略處理多媒體消息，這樣，會議系統(tǒng)中的各終端就無法正常接收到其它終端發(fā)送來的多媒體消息，從而造成了各終端 接收能力的下降，并進一步降低了會議質(zhì)量。發(fā)明內(nèi)容有鑒于此，本發(fā)明實施例的主要目的在于提供一種在基于SIP的會議系 統(tǒng)中向終端發(fā)送多媒體消息的方法，能夠提高終端對多媒體消息的接收能力。本發(fā)明實施例的另一個目的在于提供一種在基于SIP的會議系統(tǒng)中向 終端發(fā)送多媒體消息的系統(tǒng)，能夠提高終端對多媒體消息的接收能力。本發(fā)明實施例的第三個目的在于提供一種在基于SIP的會議系統(tǒng)中向終端發(fā)送多媒體消息的會議中心服務(wù)器，能夠提高終端對多媒體消息的接收能力。為達到上述目的，本發(fā)明實施例的技術(shù)方案是這樣實現(xiàn)的一種在基于會話初始協(xié)議SIP的會議系統(tǒng)中向終端發(fā)送多媒體消息的方 法，該方法包括以下步驟會議中心服務(wù)器接收來自發(fā)送方終端的多媒體消息；會議中心服務(wù)器判斷接收方終端是否支持所述多4某體消息，若不支持，則 根據(jù)預(yù)先配置的會議策略對所述多媒體消息進行操作。一種在基于SIP的會議系統(tǒng)中向終端發(fā)送多媒體消息的系統(tǒng)，該系統(tǒng)包括 發(fā)送方終端、接收方終端以及會議中心服務(wù)器，關(guān)鍵在于；所述會議中心服務(wù)器，用于接收來自發(fā)送方終端的多媒體消息，并判斷接 收方終端是否支持所述多媒體消息，若不支持，則根據(jù)預(yù)先配置的會議策略對 所述多媒體消息進行操作。一種在基于SIP的會議系統(tǒng)中向終端發(fā)送多媒體消息的會議中心服務(wù)器， 該會議中心服務(wù)器包括信息接收提取模塊、終端能力存儲模塊和會議策略執(zhí) 行模塊；所述信息接收提取沖莫塊，用于接收來自發(fā)送方終端的多媒體消息，并提取所述多々某體消息的特征信息，將提取出的特征信息發(fā)送給會議策略4丸行模塊； 所述終端能力存儲模塊，用于存儲系統(tǒng)中各終端的協(xié)商能力信息，并在接收到會議策略執(zhí)行模塊的協(xié)商能力提取請求后，向會議策略執(zhí)行模塊回送接收方終端的協(xié)商能力信息；所述會議策略執(zhí)行模塊，用于接收來自信息接收提取模塊的多媒體消息的特征信息，并向終端能力存儲模塊發(fā)送協(xié)商能力提取請求，根據(jù)所述終端能力存儲模塊回送的接收方終端協(xié)商能力信息判斷接收方終端是否支持所述多媒體消息的特征信息，若不支持，則根據(jù)預(yù)先配置的會議策略對所述多i某體消息進行操作?？梢?，采用本發(fā)明實施例的技術(shù)方案，會議中心服務(wù)器在接收到發(fā)送方 終端的多媒體消息后，首先會判斷該多媒體消息是否能夠得到接收方終端的 支持，若得不到支持，則可根據(jù)會議策略進行相應(yīng)處理，從而提高該多媒體 消息被接收的機率，即提高接收方終端的接收能力，進而提高會議質(zhì)量。


圖1為MMS中的點到點業(yè)務(wù)實現(xiàn)流程圖；圖2為本發(fā)明系統(tǒng)實施例結(jié)構(gòu)示意圖；圖3為本發(fā)明會議中心服務(wù)器結(jié)構(gòu)示意圖；圖4為本發(fā)明系統(tǒng)一個較佳實施例結(jié)構(gòu)示意圖；圖5為本發(fā)明方法實施例總體流程圖；圖6為本發(fā)明方法第一個較佳實施例的流程圖；圖7為本發(fā)明方法第二個較佳實施例的流程圖；圖8為本發(fā)明方法第三個較佳實施例的流程圖；圖9為本發(fā)明方法第四個較佳實施例的流程圖。
具體實施方式
為使本發(fā)明的目的、技術(shù)方案及優(yōu)點更加清楚明白，以下參照附圖并舉實施例，對本發(fā)明作進一步地詳細說明。需要說明的是，本發(fā)明的會議系統(tǒng)為基 于SIP的會議系統(tǒng)。圖2為本發(fā)明系統(tǒng)實施例結(jié)構(gòu)示意圖，如圖2所示，該系統(tǒng)至少包括發(fā)送 方終端201、接收方終端203以及會議中心服務(wù)器(Conference Server) 202。其中，Conference Server202,用于接收來自發(fā)送方終端201的多媒體消息， 并判斷接收方終端203是否支持所述多媒體消息，若不支持，則根據(jù)預(yù)先配置 的會議策略對多媒體消息進行操作。當(dāng)會議策略為直接丟棄多々某體消息并向接收方終端發(fā)送丟棄通知消息時， Conference Server202具體用于，接收來自發(fā)送方終端201的多媒體消息，判斷 接收方終端203是否支持該多媒體消息，若不支持，則丟棄該多媒體消息，并 向接收方終端203發(fā)送丟棄通知消息；Conference Server可進一步用于，向發(fā) 送方終端201發(fā)送丟棄通知消息。當(dāng)會議策略為轉(zhuǎn)存多媒體消息并向接收方終端發(fā)送轉(zhuǎn)存通知消息時，上述 系統(tǒng)進一步包括一個網(wǎng)絡(luò)存儲實體，該網(wǎng)絡(luò)存儲實體用于接收存儲來自 Conference Server202的多i某體消息，并向Conference Server202回送攜帶有存 i者地址鏈4矣或信息標(biāo)識(message ID )的響應(yīng)消息；相應(yīng)地，Conference Server202 具體用于，接收來自發(fā)送方終端201的多媒體消息，判斷接收方終端203是否 支持該多媒體消息，若不支持，則將該多媒體消息轉(zhuǎn)發(fā)給網(wǎng)絡(luò)存儲實體，并在 接收到網(wǎng)絡(luò)存儲實體的響應(yīng)消息后向接收方終端203發(fā)送轉(zhuǎn)存通知消息； Conference Server202進一步用于，向發(fā)送方終端201發(fā)送轉(zhuǎn)存通知消息。上述網(wǎng)絡(luò)存儲實體可以是一個單獨的實體，也可以位于Conference Server202或接收方終端的本地服務(wù)器中。當(dāng)會議策略為對多媒體消息進行內(nèi)容適配并將內(nèi)容適配后的多媒體消息發(fā) 送給接收方終端時，Conference Server202具體用于，接收來自發(fā)送方終端201 的多媒體消息，判斷接收方終端203是否支持該多媒體消息，若不支持，則對 該多i某體消息進行內(nèi)容適配，并將適配成功后的多々某體消息發(fā)送給接收方終端 203; Conference Server202還可進一步用于，對內(nèi)容適配不成功的多媒體消息，直接丟棄或進行轉(zhuǎn)存，并向接收方終端203發(fā)送丟棄或轉(zhuǎn)存通知消息。圖3為本發(fā)明Conference Server202結(jié)構(gòu)示意圖，如圖3所示，C onference Server202包括信息接收提取模塊301 、終端能力存儲模塊302和會議策略執(zhí)行 模塊303。信息接收提取模塊301，用于接收來自發(fā)送方終端201的多媒體消息，并 提取該多媒體消息的特征信息，將提取出的特征信息發(fā)送給會議策略執(zhí)行模塊 303;終端能力存儲模塊302，用于存儲系統(tǒng)中各終端的協(xié)商能力信息，并在接 收到會議策略執(zhí)行模塊303的協(xié)商能力提取請求后，向會議策略執(zhí)行模塊303 回送接收方終端203的協(xié)商能力信息；會議策略執(zhí)行模塊303,用于接收來自信息接收提取模塊301的多媒體消 息的特征信息，并向終端能力存儲模塊302發(fā)送協(xié)商能力提取請求，根據(jù)終端 能力存儲模塊302回送的接收方終端203協(xié)商能力信息判斷接收方終端203是 否支持所述多媒體特征信息，若不支持，則根據(jù)預(yù)先配置的會議策略對該多媒 體消息進行操作。根據(jù)操作方式的不同，會議策略執(zhí)行模塊303具體用于，將多媒體消息進 行丟棄或轉(zhuǎn)存，并向接收方終端203發(fā)送丟棄或轉(zhuǎn)存通知消息；或者，用于對 多媒體消息進行內(nèi)容適配，并將內(nèi)容適配后的多媒體消息轉(zhuǎn)發(fā)給接收方終端 203;會議策略執(zhí)行模塊303還可進一步用于，向發(fā)送方終端201發(fā)送丟棄或轉(zhuǎn) 存通知消息。上述Conference Server202還可進一 步包括一個網(wǎng)絡(luò)存儲實體304,用于接 收并存儲來自會議策略執(zhí)行模塊303的多媒體消息，并向會議策略執(zhí)行模塊303 回送該多媒體消息的存儲地址鏈接?；谏鲜鼋榻B，圖4為本發(fā)明系統(tǒng)一個較佳實施例結(jié)構(gòu)示意圖，本實施例 為會議策略為轉(zhuǎn)存多媒體消息并向接收方終端發(fā)送轉(zhuǎn)存通知消息，且網(wǎng)絡(luò)存儲 實體為一個單獨的功能實體時的系統(tǒng)結(jié)構(gòu)示意圖。如圖4所示，該系統(tǒng)主要包 括發(fā)送方終端401、 Conference Server402、網(wǎng)絡(luò)存儲實體403以及接收方終端405，同時，由于本實施例系統(tǒng)為基于SIP的會議系統(tǒng)，所以系統(tǒng)中進一步包括 SIP/IP核心網(wǎng)404。發(fā)送方終端401通過建立會議時所建立的消息會話中繼協(xié)議(MSRP)通 道向Conference Server402發(fā)送多4某體消息；Conference Server402接收到多媒 體消息后，提取該多媒體消息的特征信息，比如媒體類型、消息大小以及消息 長度等，本實施例中假設(shè)只提取媒體類型信息，Conference Server402查詢自身 存儲的終端協(xié)商能力信息，將提取出的+某體類型與接收方終端405的協(xié)商能力 進行比較，發(fā)現(xiàn)接收方終端405不支持該媒體類型，則根據(jù)預(yù)先配置的會議策 略決定將該多媒體消息轉(zhuǎn)存到網(wǎng)絡(luò)存儲實體403中；Conference Server402將網(wǎng) 絡(luò)存儲實體403看作一個普通參會用戶，將其加入到會議系統(tǒng)中，并向網(wǎng)絡(luò)存 儲實體403發(fā)送上述多媒體消息；網(wǎng)絡(luò)存儲實體403接收并存儲該多媒體消息， 并向Conference Server402回送攜帶有該多媒體消息存儲地址鏈接的響應(yīng)消息， 之后，網(wǎng)絡(luò)存儲實體403可以選擇退出會議，也可以選擇一直參加會議，直至 結(jié)束；Conference Server402接收到來自網(wǎng)絡(luò)存儲實體403的響應(yīng)消息后，通過 SIP/IP核心網(wǎng)404向接收方終端405發(fā)送轉(zhuǎn)存通知消息；接收方終端405根據(jù) 所述轉(zhuǎn)存通知消息獲知由于自己終端協(xié)商能力不支持， 一個發(fā)送給自己的多媒 體消息已^皮轉(zhuǎn)存到網(wǎng)絡(luò)存儲實體403中，接收方終端405還可通過該轉(zhuǎn)發(fā)通知 消息得知發(fā)送該多媒體消息的終端名稱、該多媒體消息的名稱以及類型等信息； 4妻收方終端405向Conference Server402回送響應(yīng)消息。如果之后接收方終端 405想要獲取該多媒體消息，可通過其自身終端或其它方式比如更換一個支持 該多媒體消息的終端，根據(jù)該多媒體消息的存儲地址鏈接提取到該多媒體消息。其它可能的系統(tǒng)較佳組成結(jié)構(gòu)無非是根據(jù)會議策略的不同，不包括網(wǎng)絡(luò)存 儲實體或網(wǎng)絡(luò)存儲實體位于Conference Server或接收方終端的本地服務(wù)器中， 本領(lǐng)域4支術(shù)人員根據(jù)上迷介紹可以較為容易的推導(dǎo)出來，此處不再贅述。圖5為本發(fā)明方法總體實施例流程圖，本發(fā)明的方案都是在H沒已經(jīng)建立 了會議的基礎(chǔ)上進行的，如圖5所示，包括以下步驟步驟501: Conference Server接收來自發(fā)送方終端的多媒體消息。發(fā)送方終端通過建立會議時所建立的MSRP通道向Conference Server發(fā)送 多媒體消息，該多媒體消息可以攜帶在MSRP發(fā)送(SEND)請求消息中或其 它的SIP消息中，Conference Server接收到該多媒體消息后，向發(fā)送方終端回 送響應(yīng)消息。步驟502: Conference Server判斷接收方終端是否支持該多媒體消息，若不 支持，則根據(jù)預(yù)先配置的會議策略對該多媒體消息進行操作。本步驟中，Conference Server判斷接收方終端是否支持該多4某體消息的方 式為Conference Server提取該多媒體消息的特征信息，比如媒體類型、消息 大d、以及消息長度等，并根據(jù)預(yù)先存儲的終端協(xié)商能力信息判斷接收方終端的 協(xié)商能力是否支持該多々某體消息特征。上述預(yù)先存儲的終端協(xié)商能力信息為終 端初始加入會議系統(tǒng)時與Conference Server協(xié)商支持的能力信息，比如終端支 持的媒體類型、消息大小以及消息長度等。若上述判斷過程顯示接收方終端支持該多媒體消息，則Conference Server 將該多媒體消息發(fā)送給接收方終端，接收方終端對該消息進行相關(guān)處理，這些 均為現(xiàn)有技術(shù)，不再介紹；若不支持，則Conference Server才艮據(jù)預(yù)先配置的會 議策略進行相應(yīng)處理，這里所說預(yù)先配置是指會議建立時在Conference Server 中統(tǒng)一配置，或是后來由Conference Server配置，或是在終端初始加入會議時 在Conference Server中配置；所述會議策略可以為直接丟棄該多媒體消息并 向發(fā)送方終端發(fā)送丟棄通知消息、轉(zhuǎn)存該多媒體消息并向發(fā)送方終端發(fā)送轉(zhuǎn)存 通知消息，或?qū)υ摱嗝襟w消息進行內(nèi)容適配并將內(nèi)容適配后的多媒體消息發(fā)送 給接收方終端。不同的會議策略對應(yīng)著不同的處理方法(1 )當(dāng)會議策略為直接丟棄該多媒體消息并向發(fā)送方終端發(fā)送丟棄通知消 息時，包括以下步驟Conference Server丟棄該多々某體消息；Conference Server向接收方終端發(fā)送 丟棄通知消息；接收方終端向Conference Server回送響應(yīng)消息。若多媒體消息中攜帶有一個以上媒體內(nèi)容，且接收方終端不支持其中的部分媒體內(nèi)容時，Conference Server可以將能夠得到接收方終端支持的々某體內(nèi)容 直接發(fā)送給接收方終端，而將得不到接收方終端支持的媒體內(nèi)容進行丟棄；或 者，直接將所有媒體內(nèi)容進行丟棄。該方法可進一步包括Conference Server向發(fā)送方終端發(fā)送丟棄通知消息。 (2 )當(dāng)會議策略為轉(zhuǎn)存該多媒體消息并向發(fā)送方終端發(fā)送轉(zhuǎn)存通知消息 時，包括以下步驟Conference Server將該多媒體消息轉(zhuǎn)存到會議中心的網(wǎng)絡(luò)存儲實體中，所 述會議中心的網(wǎng)絡(luò)存儲實體向Conference Server回送攜帶有多媒體消息存儲地 址鏈接的響應(yīng)消息；或者，Conference Server將該多媒體消息轉(zhuǎn)存到接收方終 端本地的網(wǎng)絡(luò)存儲實體中，所述接收方終端本地的網(wǎng)絡(luò)存儲實體向Conference Server回送攜帶有message ID的響應(yīng)消息；Conference Server向接收方終端發(fā)送攜帶有存儲地址鏈接或message ID的 轉(zhuǎn)存通知消息；4妄收方終端向Conference Server回送響應(yīng)消息。同樣，若所述多媒體消息中攜帶有一個以上媒體內(nèi)容，且接收方終端不支 持其中的部分士某體內(nèi)容時，Conference Server可以將能夠得到接收方終端支持 的媒體內(nèi)容直接發(fā)送給接收方終端，將得不到接收方支持的媒體內(nèi)容進行轉(zhuǎn)存； 或者，將所有媒體內(nèi)容進行轉(zhuǎn)存。該方法可進一步包括Conference Server向發(fā)送方終端發(fā)送轉(zhuǎn)存通知消息。若接收方終端以后想要獲取轉(zhuǎn)存的多媒體消息，可以根據(jù)存儲地址鏈接或 message ID提取該多媒體消息。(3 )當(dāng)會議策略為將該多力某體消息進行內(nèi)容適配并將內(nèi)容適配后的多媒體 消息發(fā)送給接收方終端時，包括以下步驟Conference Server對該多媒體消息進行內(nèi)容適配，若內(nèi)容適配成功，則將 內(nèi)容適配后的多々某體消息發(fā)送給接收方終端；接收方終端對內(nèi)容適配后的多媒 體消息進4亍處理，并向Conference Server回送響應(yīng)消息；若適配不成功，則Conference Server繼續(xù)按照直接丟棄該多媒體消息并向 接收方終端發(fā)送丟棄通知消息或轉(zhuǎn)存該多媒體消息并向接收方終端發(fā)送轉(zhuǎn)存通知消息的方法對該多媒體消息進行處理。圖6為本發(fā)明方法第一個較佳實施例的流程圖，本實施例采用直接丟棄后 發(fā)送丟棄通知的方式處理得不到接收方終端支持的多々某體消息，如圖6所示，包括以下步驟步驟601:會議系統(tǒng)中的某一個參會者要向其他參會者發(fā)送多媒體消息， 由該參會者的終端，即發(fā)送方終端通過建立會議時所建立的MSRP通道向 Conference Server發(fā)送MSRP SEND請求消息。MSRP SEND請求消息中攜帶有發(fā)送方終端所要發(fā)送的多媒體消息，該 MSRP SEND請求消息通過SIP/IP核心網(wǎng)發(fā)送到Conference Server。步驟602: Conference Server接收到MSRP SEND請求消息后，向發(fā)送方 終端回送MSRP 200 OK響應(yīng)消息。步驟603: Conference Server判斷接收方終端是否支持該多媒體消息，若不 支持，則將該多士某體消息丟棄。Conference Server判斷接收方終端是否支持該多媒體消息的方法為 Conference Server提取該多媒體消息的特征信息，比如，媒體類型、消息長度 等，本實施例中假設(shè)只提取媒體類型信息，并通過查詢自身存儲的接收方終端 協(xié)商能力信息來判斷接收方終端是否支持該媒體類型，若支持，則按現(xiàn)有技術(shù) 進行處理；若不支持，則將該多々某體消息丟棄。步驟604 ~ 605: Conference Server通過SIP/IP核心網(wǎng)向接收方終端發(fā)送丟 棄通知消息，本實施例中的丟棄通知消息為一個SIP消息(MESSAGE )。SIP MESSAGE中攜帶有多媒體消息已被丟棄、發(fā)送該多媒體消息的終端、 該多媒體消息的名稱以及類型等信息。上述丟棄通知消息通過SIP/IP核心網(wǎng)轉(zhuǎn)發(fā)，在實際應(yīng)用中，也可以通過 MSRP通道或其它的如預(yù)定(SUBSCRIBE) /通知(NOTIFY)方式發(fā)送給接收 方終端。步驟606:接收方終端根據(jù)接收到的SIP MESSAGE得知一個參會者曾向自 己發(fā)送了多媒體消息，但由于得不到自身終端的支持該多媒體消息已被丟棄。步驟607 ~ 608:接收方終端通過SIP/IP核心網(wǎng)向Conference Server回送200 OK響應(yīng)消息。Conference Server還可進一步向發(fā)送方終端發(fā)送丟棄通知消息，以通知發(fā) 送方終端其發(fā)送給哪些終端以及發(fā)送的哪些多媒體消息被丟棄。需要說明的是，若發(fā)送方終端發(fā)送的多媒體消息中包含有多個媒體內(nèi)容， 而接收方終端只是不支持其中的一個或幾個媒體內(nèi)容而不是全部時， Conference Server可以根據(jù)會議策略，選擇丟棄所有的媒體內(nèi)容或只是丟棄接 收方終端不支持的々某體內(nèi)容。圖7為本發(fā)明方法第二個較佳實施例的流程圖，本實施例采用轉(zhuǎn)存后發(fā)送 轉(zhuǎn)存通知的方式處理得不到接收方終端支持的多媒體消息，且網(wǎng)絡(luò)存儲實體 (NS)是一個單獨的功能實體，如圖7所示，包括以下步驟步驟701:發(fā)送方終端通過建立會議時所建立的MSRP通道向Conference Server發(fā)送MSRP SEND請求消息。MSRP SEND請求消息中攜帶有發(fā)送方終端所要發(fā)送的多媒體消息，該 MSRP SEND請求消息通過SIP/IP核心網(wǎng)發(fā)送到Conference Server。步驟702: Conference Server接收到MSRP SEND請求消息后，向發(fā)送方 終端回送MSRP 200 OK響應(yīng)消息。步驟703: Conference Server判斷接收方終端是否支持該多媒體消息，若不 支持，則決定將該多々某體消息轉(zhuǎn)存。Conference Server判斷接收方終端是否支持該多媒體消息的方法為 Conference Server提取該多媒體消息的特征信息，比如，媒體類型、信息長度 等，本實施例中假設(shè)只提取媒體類型信息，并通過查詢自身存儲的接收方終端 協(xié)商能力信息來判斷接收方終端是否支持該媒體類型，若支持，則按現(xiàn)有技術(shù) 進行處理；若不支持，則執(zhí)行步驟704。步驟704: Conference Server將該多媒體消息發(fā)送給NS。本實施例中的NS是一個單獨的網(wǎng)絡(luò)實體或者是會議中心統(tǒng)一的網(wǎng)絡(luò)存儲 實體，Conference Server在向其發(fā)送多媒體消息之前已經(jīng)與NS建立了連接通道，建立方法為將NS看作一個參會者，按照現(xiàn)有技術(shù)中將參會者加入會議的 方式將NS加入到會議系統(tǒng)中，這樣，Conference Server即可通過建立的MSRP 通道向NS發(fā)送多媒體消息。步驟705: NS接收并存儲該多媒體消息后，向Conference Server回送響應(yīng) 消息，響應(yīng)消息中攜帶有該多媒體消息所存儲的地址鏈接。回送響應(yīng)消息之后，NS可以選擇退出會議，也可選擇繼續(xù)參加會議，直至 會議結(jié)束。步驟706 ~ 707: Conference Server通過SIP/IP核心網(wǎng)向接收方終端發(fā)送轉(zhuǎn)存通知消息，本實施例中的轉(zhuǎn)存通知消息為一個sipMi:ssAG〖:。SIP MESSAGE中攜帶有多媒體消息已被轉(zhuǎn)存、發(fā)送該多媒體消息的終端、 該多媒體消息的名稱、類型以及轉(zhuǎn)存地址鏈接等信息。步驟708:接收方終端根據(jù)接收到的SIP MESSAGE得知一個參會者曾向自 己發(fā)送了多媒體消息，但由于得不到自身終端的支持該多媒體消息已被轉(zhuǎn)存到 NS中。根據(jù)SIP MESSAGE中的地址鏈接信息，接收方終端可以在以后通過自身 終端或以其它方式，比如更換一個支持上述多媒體類型的終端來獲取所述多媒 體消息。步驟709 ~ 710:接收方終端通過SIP/IP核心網(wǎng)向Conference Server回送200OK響應(yīng)消息。Conference Server還可進一步向發(fā)送方終端發(fā)送轉(zhuǎn)存通知消息，以通知發(fā) 送方終端其發(fā)送給哪些終端以及發(fā)送的哪些多媒體消息被轉(zhuǎn)存。需要說明的是，若發(fā)送方終端發(fā)送的多媒體消息中包含有多個媒體內(nèi)容， 而接收方終端只是不支持其中的一個或幾個媒體內(nèi)容而不是全部時， Conference Server可以沖艮據(jù)會議策略，選擇轉(zhuǎn)存所有的媒體內(nèi)容或只是轉(zhuǎn)存接 收方終端不支持的媒體內(nèi)容。圖8為本發(fā)明方法第三個較佳實施例的流程圖，本實施例同樣采用轉(zhuǎn)存后 發(fā)送轉(zhuǎn)存通知的方式處理得不到接收方終端支持的多士某體消息，與實施例二相比區(qū)別僅在于本實施例中將得不到接收方終端支持的多媒體消息轉(zhuǎn)存到接收 方終端本地服務(wù)器的NS中，NS不再作為一個單獨的功能實體出現(xiàn)；相應(yīng)地， 本地服務(wù)器在存儲多媒體消息后，向Conference Server回送的響應(yīng)消息中攜帶 有Message ID信息而不是存儲地址鏈接信息。其它流程與實施例二類似，不再贅述。圖9為本發(fā)明方法第四個較佳實施例的流程圖，本實施例采用進行內(nèi)容適 配的方式處理得不到接收方終端支持的多媒體消息，如圖9所示，包括以下步 驟步驟901:發(fā)送方終端通過建立會議時所建立的MSRP通道向Conference Server發(fā)送MSRP SEND請求消息。MSRP SEND請求消息中攜帶有發(fā)送方終端所要發(fā)送的多媒體消息，該 MSRP SEND請求消息通過SIP/IP核心網(wǎng)發(fā)送到Conference Server。步驟902: Conference Server接收到MSRP SEND請求消息后，向發(fā)送方 終端回送MSRP 200 OK響應(yīng)消息。步驟卯3: Conference Server判斷接收方終端是否支持該多媒體消息，若不 支持，則將該多力某體消息直接丟棄。Conference Server判斷接收方終端是否支持該多媒體消息的方法為 Conference Server提取該多媒體消息的特征信息，比如，媒體類型、信息長度 等，本實施例中假設(shè)只提取媒體類型信息，并通過查詢自身存儲的接收方終端 協(xié)商能力信息來判斷接收方終端是否支持該媒體類型，若支持，則按現(xiàn)有技術(shù) 進行處理；若不支持，則對該多媒體消息進行內(nèi)容適配，即Conference Server接收自發(fā)送方終端的媒體類型轉(zhuǎn)換為接收方終端支持的媒體類型。比如，發(fā)送方終端向接收方終端發(fā)送了一個可交換圖像格式(GIF)的圖 片，而接收方終端只能接收聯(lián)合圖像專家組格式(JPEG)的圖片，那么， Conference Server就需要在本步驟中將GIF格式圖片轉(zhuǎn)換為JPEG格式圖片。 步驟904-905: Conference Server通過SIP/IP核心網(wǎng)向接收方終端發(fā)送:'J，將MSRP SEND請求消息。MSRP SEND請求消息中攜帶有經(jīng)過內(nèi)容適配后的多媒體消息。步驟906:接收方終端對接收到的經(jīng)過內(nèi)容適配后的多媒體消息進行相關(guān)處理。步驟907 ~ 908:接收方終端通過SIP/IP核心網(wǎng)向Conference Server回送200 OK響應(yīng)消息。需要說明的是，若內(nèi)容適配不成功，Conference Server可繼續(xù)按照實施例 一、二或三中所述的方法對該多媒體消息進行處理?？梢姡捎帽景l(fā)明實施例的技術(shù)方案，提高了接收方終端對多媒體消息的 接收能力，增強了參會者的參會能力，改善了參會者的業(yè)務(wù)體驗，提高了會議質(zhì)量。綜上所述，以上僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的 保護范圍。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改 進等，均應(yīng)包舍在本發(fā)明的保護范圍之內(nèi)。
權(quán)利要求
1. 一種在基于會話初始協(xié)議SIP的會議系統(tǒng)中向終端發(fā)送多媒體消息的方法，其特征在于，該方法包括以下步驟會議中心服務(wù)器接收來自發(fā)送方終端的多媒體消息；會議中心服務(wù)器判斷接收方終端是否支持所述多媒體消息，若不支持，則根據(jù)預(yù)先配置的會議策略對所述多媒體消息進行操作。
2、 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述會議中心服務(wù)器判斷接 收方終端是否支持所述多i某體消息的步驟包括會議中心服務(wù)器提取多媒體消息的特征信息，并根據(jù)預(yù)先存儲的終端協(xié)商 能力信息判斷所述接收方終端的協(xié)商能力是否支持所述多媒體消息的特征。
3、 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述會議中心服務(wù)器根據(jù)預(yù) 先配置的會議策略對所述多媒體消息進行操作的步驟包括會議中心服務(wù)器丟棄所述多媒體消息；會議中心服務(wù)器向接收方終端發(fā)送 丟棄通知消息；接收方終端向會議中心服務(wù)器回送響應(yīng)消息。
4、 根據(jù)權(quán)利要求3所述的方法，其特征在于，所述多^某體消息中攜帶有一 個以上媒體內(nèi)容，且接收方終端不支持其中的部分媒體內(nèi)容，則會議中心服務(wù) 器丟棄所述多媒體消息的步驟包括會議中心服務(wù)器將能夠得到接收方終端支持的媒體內(nèi)容直接發(fā)送給接收方 終端，將得不到接收方終端支持的媒體內(nèi)容進行丟棄；或者，直接將所有媒體 內(nèi)容進4亍丟棄。
5、 根據(jù)權(quán)利要求3或4所述的方法，其特征在于，該方法進一步包括會 議中心服務(wù)器向發(fā)送方終端發(fā)送丟棄通知消息。
6、 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述會議中心服務(wù)器根據(jù)預(yù) 先配置的會議策略對所述多媒體消息進行操作的步驟包括會議中心服務(wù)器將所述多媒體消息轉(zhuǎn)存到會議中心的網(wǎng)絡(luò)存儲實體中，所 述會議中心的網(wǎng)絡(luò)存儲實體向會議中心服務(wù)器回送攜帶有多媒體消息存儲地址鏈接的響應(yīng)消息；或者，會議中心服務(wù)器將所述多媒體消息轉(zhuǎn)存到接收方終端 本地的網(wǎng)絡(luò)存儲實體中，所述接收方終端本地的網(wǎng)絡(luò)存儲實體向會議中心服務(wù) 器回送攜帶有信息標(biāo)識message ID的響應(yīng)消息；會議中心服務(wù)器向接收方終端發(fā)送攜帶有存儲地址鏈接或message ID的轉(zhuǎn) 存通知消息；接收方終端向會議中心"良務(wù)器回送響應(yīng)消息。
7、 根據(jù)權(quán)利要求6所述的方法，其特征在于，所述多媒體消息中攜帶有一 個以上媒體內(nèi)容，且接收方終端不支持其中的部分媒體內(nèi)容，則會議中心服務(wù) 器轉(zhuǎn)存所述多媒體消息的步驟包括會議中心服務(wù)器將能夠得到接收方終端支持的媒體內(nèi)容直接發(fā)送給接收方 終端，將得不到接收方支持的媒體內(nèi)容進行轉(zhuǎn)存；或者，將所有媒體內(nèi)容進行 轉(zhuǎn)存。
8、 根據(jù)權(quán)利要求6或7所述的方法，其特征在于，該方法進一步包括會 議中心服務(wù)器向發(fā)送方終端發(fā)送轉(zhuǎn)存通知消息。
9、 根據(jù)權(quán)利要求8所述的方法，其特征在于，該方法進一步包括所述接 收方終端根據(jù)存儲地址鏈接或message ID提取所述多媒體消息。
10、 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述會議中心服務(wù)器根據(jù) 預(yù)先配置的會議策略對所述多媒體消息進行操作的步驟包括會議中心服務(wù)器對所述多媒體消息進行內(nèi)容適配，若內(nèi)容適配成功，則將 內(nèi)容適配后的多々某體消息發(fā)送給接收方終端；接收方終端對所述內(nèi)容適配后的 多媒體消息進行處理，并向會議中心服務(wù)器回送響應(yīng)消息。
11、 根據(jù)權(quán)利要求IO所述的方法，其特征在于，該方法進一步包括 若適配不成功，則會議中心服務(wù)器繼續(xù)按照直接丟棄所述多媒體消息并向發(fā)送方終端發(fā)送丟棄通知消息或轉(zhuǎn)存所述多士某體消息并向發(fā)送方終端發(fā)送轉(zhuǎn)存 通知消息的方法對所述多^某體消息進行處理。
12、 一種在基于SIP的會議系統(tǒng)中向終端發(fā)送多媒體消息的系統(tǒng)，該系統(tǒng) 包括發(fā)送方終端、接收方終端以及會議中心服務(wù)器，其特征在于；所述會議中心服務(wù)器，用于接收來自發(fā)送方終端的多媒體消息，并判斷接收方終端是否支持所述多媒體消息，若不支持，則根據(jù)預(yù)先配置的會議策略對 所述多々某體消息進行操作。
13、 根據(jù)權(quán)利要求12所述的系統(tǒng)，其特征在于，當(dāng)會議策略為直接丟棄所 述多^(某體消息并向接收方終端發(fā)送丟棄通知消息時；所述會議中心服務(wù)器具體用于，接收來自發(fā)送方終端的多i某體消息，判斷 接收方終端是否支持所述多媒體消息，若不支持，則丟棄所述多媒體消息，并 向接收方終端發(fā)送丟棄通知消息。
14、 根據(jù)權(quán)利要求13所述的系統(tǒng)，其特征在于，所述會議中心服務(wù)器進一 步用于，向發(fā)送方終端發(fā)送丟棄通知消息。
15、 根據(jù)權(quán)利要求12所述的系統(tǒng)，其特征在于，當(dāng)會議策略為轉(zhuǎn)存所述多 媒體消息并向接收方終端發(fā)送轉(zhuǎn)存通知消息時，該系統(tǒng)進一步包括一個網(wǎng)絡(luò)存 儲實體；所述網(wǎng)絡(luò)存儲實體，用于接收和存儲來自會議中心服務(wù)器的多媒體消息， 并向會議中心服務(wù)器回送攜帶有存儲地址鏈接或message ID的響應(yīng)消息；所述會議中心服務(wù)器具體用于，接收來自發(fā)送方終端的多^某體消息，判斷 接收方終端是否支持所述多i某體消息，若不支持，則將所述多i某體消息轉(zhuǎn)發(fā)給 網(wǎng)絡(luò)存儲實體，并在接收到所述網(wǎng)絡(luò)存儲實體的響應(yīng)消息后向接收方終端發(fā)送 轉(zhuǎn)存通知消息。
16、 根據(jù)權(quán)利要求15所述的系統(tǒng)，其特征在于，所述會議中心服務(wù)器進一 步用于，向發(fā)送方終端發(fā)送轉(zhuǎn)存通知消息。
17、 根據(jù)權(quán)利要求15或16所述的系統(tǒng)，其特征在于，所述網(wǎng)絡(luò)存儲實體 為一個單獨的實體，或位于會議中心服務(wù)器中，或位于接收方終端的本地服務(wù)器中。
18、 根據(jù)權(quán)利要求12所述的系統(tǒng)，其特征在于，當(dāng)會議策略為對所述多媒所述會議中心服務(wù)器具體用于，接收來自發(fā)送方終端的多媒體消息，判斷 接收方終端是否支持所述多4某體消息，若不支持，則對所述多々某體消息進行內(nèi)容適配，并將內(nèi)容適配成功后的多媒體消息發(fā)送給接收方終端。
19、 根據(jù)權(quán)利要求18所述的系統(tǒng)，其特征在于，所述會議中心服務(wù)器進一步用于，對內(nèi)容適配不成功的多媒體消息，直接丟棄或進行轉(zhuǎn)存，并向接收方 終端發(fā)送丟棄或轉(zhuǎn)存通知消息。
20、 一種在基于SIP的會議系統(tǒng)中向終端發(fā)送多媒體消息的會議中心服務(wù) 器，其特征在于，該會議中心服務(wù)器包括信息接收提取模塊、終端能力存儲 模塊和會議策略執(zhí)行模塊；所述信息接收提取模塊，用于接收來自發(fā)送方終端的多媒體消息，并提取 所述多媒體消息的特征信息，將提取出的特征信息發(fā)送給會議策略執(zhí)行模塊；所述終端能力存儲模塊，用于存儲系統(tǒng)中各終端的協(xié)商能力信息，并在接 收到會議策略執(zhí)行模塊的協(xié)商能力提取請求后，向會議策略執(zhí)行模塊回送接收 方終端的協(xié)商能力信息；所述會議策略執(zhí)行模塊，用于接收來自信息接收提取模塊的多媒體消息的 特征信息，并向終端能力存儲模塊發(fā)送協(xié)商能力提取請求，根據(jù)所述終端能力 存儲模塊回送的接收方終端協(xié)商能力信息判斷接收方終端是否支持所述多媒體消息的特征信息，若不支持，則才艮據(jù)預(yù)先配置的會議策略對所述多媒體消息進 行操作。
21、 根據(jù)權(quán)利要求20所述的會議中心服務(wù)器，其特征在于，所述會議策略 執(zhí)行模塊進一步用于，將所述多媒體消息進行丟棄或轉(zhuǎn)存，并向接收方終端發(fā) 送丟棄或轉(zhuǎn)存通知消息；或者，用于對所述多媒體消息進行內(nèi)容適配，并將內(nèi) 容適配成功后的多媒體消息轉(zhuǎn)發(fā)給接收方終端。
22、 根據(jù)權(quán)利要求21所述的會議中心服務(wù)器，其特征在于，所述會議策略 執(zhí)行模塊進一步用于，向發(fā)送方終端發(fā)送丟棄或轉(zhuǎn)存通知消息。
23、 根據(jù)權(quán)利要求20 22中任一項所述的會議中心服務(wù)器，其特征在于， 所述會議中心服務(wù)器進一步包括一個網(wǎng)絡(luò)存儲模塊，用于接收并存儲來自會議 策略執(zhí)行模塊的多媒體消息，并向會議策略執(zhí)行模塊回送所述多媒體消息的存 儲地址鏈接。
全文摘要
本發(fā)明實施例公開了一種在基于會話初始協(xié)議(SIP)的會議系統(tǒng)中向終端發(fā)送多媒體消息的方法，會議中心服務(wù)器接收來自發(fā)送方終端的多媒體消息；會議中心服務(wù)器判斷接收方終端是否支持所述多媒體消息，若不支持，則根據(jù)預(yù)先配置的會議策略對所述多媒體消息進行操作。本發(fā)明實施例還同時公開了一種在基于SIP的會議系統(tǒng)中向終端發(fā)送多媒體消息的系統(tǒng)和會議中心服務(wù)器，應(yīng)用該方法、系統(tǒng)以及會議中心服務(wù)器可以提高終端對多媒體消息的接收能力，相應(yīng)的提高會議質(zhì)量。
文檔編號H04Q7/22GK101237337SQ200710006459
公開日2008年8月6日 申請日期2007年1月30日 優(yōu)先權(quán)日2007年1月30日
發(fā)明者剛 梁, 牟倫健, 玨 王, 王嘯波, 許國軍, 成 黃 申請人:華為技術(shù)有限公司