• / 52
  • 下載費用:30 金幣  

在融合互聯網協議消息服務中控制用于互配的會話的方法和裝置及其系統.pdf

摘要
申請專利號:

CN200980155456.2

申請日:

2009.11.27

公開號:

CN102301754B

公開日:

2015.01.07

當前法律狀態:

授權

有效性:

有權

法律詳情: 授權|||實質審查的生效IPC(主分類):H04W 4/12申請日:20091127|||公開
IPC分類號: H04W4/12 主分類號: H04W4/12
申請人: 三星電子株式會社
發明人: 李升勇; 李炅卓; 樸成真
地址: 韓國京畿道
優先權: 2008.11.28 KR 10-2008-0120164; 2008.12.01 KR 10-2008-0120688; 2009.02.02 KR 10-2009-0008186; 2009.06.22 KR 10-2009-0055705
專利代理機構: 北京市柳沈律師事務所 11105 代理人: 蔡軍紅
PDF完整版下載: PDF下載
法律狀態
申請(專利)號:

CN200980155456.2

授權公告號:

102301754B||||||

法律狀態公告日:

2015.01.07|||2012.02.15|||2011.12.28

法律狀態類型:

授權|||實質審查的生效|||公開

摘要

公開了一種在支持訂制融合互聯網協議(IP)消息(CPM)服務的第一客戶端和沒有訂制該CPM服務的第二客戶端之間的CPM會話的CPM服務器中的會話控制方法,該會話控制方法包括:在通過CPM服務器和互配功能(IWF)在第一客戶端和第二客戶端之間發起該CPM會話之后,從第一客戶端接收包括特定媒體的會話修改請求消息;通過發起的CPM會話向IWF發送包括該特定媒體的會話修改請求消息;以及從該IWF接收響應消息,該響應消息包括對該包括特定媒體的會話修改請求消息的拒絕理由。

權利要求書

1.一種在用于支持訂制融合互聯網協議(IP)消息(CPM)服務的第一
客戶端和不訂制CPM服務的第二客戶端之間的CPM會話的CPM服務器中
的會話控制方法,該會話控制方法包括步驟:
在通過CPM服務器和互配功能(IWF)在第一客戶端和第二客戶端之
間發起該CPM會話之后,從第一客戶端接收包括特定媒體的會話修改請求
消息;
通過發起的CPM會話向該IWF發送包括該特定媒體的會話修改請求消
息;以及
從該IWF接收響應消息,該響應消息包括對包括該特定媒體的會話修
改請求消息的拒絕理由。
2.如權利要求1所述的會話控制方法,還包括:當包括在該響應消息中
的拒絕理由是該特定媒體不被該IWF支持時,向互配選擇功能(ISF)發送
對被拒絕的特定媒體的會話請求。
3.一種在用于支持訂制融合互聯網協議(IP)消息(CPM)服務的第一
客戶端和不訂制CPM服務的第二客戶端之間的CPM會話的互配功能(IWF)
中的會話控制方法,該會話控制方法包括步驟:
在通過CPM服務器和該IWF在第一客戶端和第二客戶端之間發起該
CPM會話之后,通過該CPM服務器從第一客戶端接收包括特定媒體的會話
修改請求消息;以及
當該特定媒體不被該IWF支持時,向該CPM服務器發送響應消息,該
響應消息包括指示該特定媒體不被該IWF支持的拒絕理由。
4.一種用于支持訂制融合互聯網協議(IP)消息(CPM)服務的第一客
戶端和不訂制CPM服務的第二客戶端之間的CPM會話的互配裝置,該互配
裝置包括:
至少一個互配功能(IWF),用于支持至少一個媒體的每一個,以及當
接收到對不被該IWF支持的媒體的互配請求時,產生作為相應的媒體不被
該IWF支持的指示的拒絕理由;和
互配選擇功能(ISF),用于在通過該CPM服務器和IWF在第一客戶端
和第二客戶端之間發起CPM會話之后,當通過CPM服務器從第一客戶端接
收到包括特定媒體的會話修改請求消息時,從該至少一個IWF當中選擇負
責該特定媒體的互配的實體。
5.如權利要求4所述的互配裝置,還包括控制器,用于當從IWF接收
到指示該特定媒體不被該IWF支持的拒絕理由時,指令該ISF重新選擇負責
該特定媒體的互配的實體。
6.一種在用于支持訂制融合互聯網協議(IP)消息(CPM)服務的第一
客戶端和不訂制CPM服務的第二客戶端之間的CPM會話的CPM服務器中
的會話控制方法,該會話控制方法包括步驟:
從第一客戶端接收包括特定媒體的會話發起消息;
通過互配選擇功能(ISF)向互配功能(IWF)發送包括該特定媒體的會
話發起消息;以及
通過該ISF從該IWF接收響應消息,該響應消息包括對該會話發起消息
的拒絕理由。
7.如權利要求6所述的會話控制方法,還包括:當該拒絕理由是該特定
媒體不被該IWF支持時,向該ISF重新發送包括該特定媒體的會話發起消息。
8.一種在用于支持訂制融合互聯網協議(IP)消息(CPM)服務的第一
客戶端和不訂制CPM服務的第二客戶端之間的CPM會話的互配功能(IWF)
中的會話控制方法,該會話控制方法包括步驟:
通過CPM服務器從第一客戶端接收包括特定媒體的會話發起消息;以

當該特定媒體不被該IWF支持時,向該CPM服務器發送響應消息,該
響應消息包括指示該特定媒體不被該IWF支持的拒絕理由。
9.一種用于支持訂制融合互聯網協議(IP)消息(CPM)服務的第一客
戶端和不訂制CPM服務的第二客戶端之間的CPM會話的互配裝置,該互配
裝置包括:
至少一個互配功能(IWF),用于支持至少一個媒體的每一個,以及當
接收到對不被該IWF支持的媒體的互配請求時,產生指示相應的媒體不被
該IWF支持的拒絕理由;和
互配選擇功能(ISF),用于當通過CPM服務器從第一客戶端接收到包
括特定媒體的會話發起請求消息時,從該至少一個IWF當中選擇負責該特
定媒體的互配的實體。
10.如權利要求9所述的互配裝置,還包括控制器,用于當從IWF接收
到指示該特定媒體不被該IWF支持的拒絕理由時,指令該ISF重新選擇負責
該特定媒體的互配的實體。

說明書

在融合互聯網協議消息服務中控制用于互配的會話的方法和裝置及其系統

技術領域

本發明涉及用于控制用于融合IP消息服務和非融合IP消息服務之間的
互配的會話的方法,更具體地涉及用于以發起融合IP消息服務和非融合IP
消息服務之間的會話的方式控制會話、修改已經發起的會話等等的方法。

背景技術

在現有移動環境中,終端執行一次性的消息,諸如短消息服務(SMS)
消息、多媒體消息服務(MMS)消息等等,但是用戶期望便于在有線環境
中通過即時信使與別人對話的消息服務。即時消息服務已經基于會話發起協
議/互聯網協議(SIP/IP)核心網絡被引入到終端和網絡中。此外,由于客戶
和企業對按鍵通話(例如步話機)的需要,已經開發了基于SIP/IP核心網絡
的通過蜂窩的按鍵通話(PoC)服務和系統。此外,包括企業和通信行業的
市場的急劇變化增加了對集成和處理各種類型的接收的消息的需要。

考慮到這一點,開放移動聯盟(OMA),一個建立移動解決方案和服務
的國際開放標準的標準組織,近來已經開發了通過SIP/IP核心網絡實現的融
合互聯網協議(IP)消息(CPM)服務的技術標準。

CPM服務是基于IP多媒體子系統(IMS)的消息服務,其將諸如SMS、
MMS等之類的現有消息服務集成到單個服務中并且基于IP提供集成的單個
服務。與發送/接收可能在有限的網絡和終端內的現有消息服務不同,CPM
服務不管終端的種類、媒體的類型、網絡的種類以及服務的類型如何,都提
供基于IP的融合服務。

這樣的CPM服務必須能夠集成和處理所有類型的現有消息。因此,CPM
服務需要SMS消息格式、MMS消息格式、即時消息服務消息格式、非CPM
消息格式(例如PoC)和CPM消息格式之間的相互轉換。非CPM消息格式
和CPM消息格式之間的相互轉換被稱為“互配”。

CPM服務支持與各種類型的非CPM服務的互配。當消息的發送者和接
收者屬于不同的網絡區域時,可以根據每個服務情形在發送者的網絡或接收
者的網絡中執行互配。為了提供與非CPM服務的互配,CPM系統必須配置
各種網絡實體。將參考圖1描述構成CPM系統的網絡實體的功能和相互關
系。

圖1示出了CPM系統的實體。CPM系統包括CPM客戶端110、CPM
服務器120、互配選擇功能(ISF)130、互配功能(IWF)140、SIP/IP核心
網絡150和遠程SIP/IP核心網絡151。盡管非CPM客戶端111和非CPM服
務器160不是CPM系統的實體,但是在該圖中示出了它們以便于描述CPM
系統的互配。

CPM客戶端110是指CPM服務用戶。CPM客戶端110產生融合消息以
發送給CPM服務器120,并從CPM服務器120接收另一個CPM客戶端或
非CPM客戶端111發送的消息。非CPM客戶端111是訂制非CPM服務的
客戶端,并且與相應的非CPM服務器160交換消息。

CPM服務器120處理從CPM客戶端110或另一個CPM服務器接收到
的消息。為此,CPM服務器120確定是否需要互配。也就是說,CPM服務
器120確定對于接收的消息是否需要互配以便與非CPM服務器160通信。

例如,如果CPM服務器120確定需要互配,則CPM服務器120向ISF
130傳送接收的消息。如果CPM服務器120確定不需要互配,則CPM服務
器120向接收CPM客戶端或接收CPM客戶端所屬的CPM服務器傳送接收
的消息。也就是說,當接收CPM客戶端與CPM服務器120屬于相同的網絡
區域時,CPM服務器120向該接收CPM客戶端傳送接收的消息。但是,當
接收CPM客戶端與CPM服務器120屬于不同的網絡區域時,CPM服務器
120向該不同的網絡區域的CPM服務器傳送接收的消息。此外,CPM服務
器120向與接收的消息的目的地址對應的非CPM客戶端111傳送從ISF?130
或IWF?140接收到的用于互配的消息。

ISF?130選擇能夠最有效地將從CPM服務器120接收到的消息傳送到接
收方的非CPM服務器160,并將接收的消息傳送到實際上負責與選擇的非
CPM服務器160互配的IWF?140。

IWF?140是用于提供與非CPM服務的直接互配的功能實體,并且執行
CPM和非CPM服務消息的格式之間的相互轉換以然后將轉換后的消息傳送
到非CPM服務器160。

SIP/IP核心網絡150是用于將基于SIP的服務的控制信號、由客戶端或
其服務實體產生的消息等傳送到接收者或其它實體的功能實體。為此,SIP/IP
核心網絡150可以與屬于其它提供者區域的SIP/IP核心網絡交換消息。

遠程SIP/IP核心網絡151是由另一個網絡提供者提供和管理的SIP/IP
核心網絡,并且具有與SIP/IP核心網絡150相同的功能。盡管圖1沒有示出,
但是用于提供CPM和非CPM服務的實體、設備和系統可以在遠程SIP/IP
核心網絡151中實現。

非CPM服務器160用來提供除了CPM服務之外的消息服務。由非CPM
服務器150提供的消息服務包括SMS、MMS、即時消息服務、PoC等等。

現在將參考圖2描述互配操作。圖2示出了用于CPM服務和非CPM服
務之間的互配的消息發送/接收。具體地,圖2示出了在發送CPM客戶端110
請求接收非CPM客戶端111建立會話并且CPM客戶端110請求的任何媒體
類型能夠在任何單個IWF中處理的假定之下的消息發送/接收。

在步驟201中,CPM客戶端110向CPM服務器120發送請求會話發起
的INVITE消息。INVITE消息包括用于會話描述協議(SDP)形式的會話發
起的必需信息。

在步驟203中,在從CPM客戶端110接收到INVITE消息時,CPM服
務器120檢查接收客戶端是否是CPM服務用戶并且是否處于可用狀態,從
而確定是否需要互配。當接收客戶端是非CPM客戶端時需要互配,以及當
接收客戶端是CPM客戶端并且處于可用狀態或者接收客戶端是CPM客戶端
并且處于不可用狀態時不需要互配。這里假定接收客戶端是非CPM客戶端
111。因而,在步驟205中,CPM服務器120向ISF?130傳送INVITE消息。
但是,如果不需要互配,則執行不同的操作。也就是說,當接收客戶端是
CPM客戶端并且處于可用狀態時,將INVITE消息傳送到接收CPM客戶端
以發起會話。此外,當接收客戶端是CPM客戶端并且處于不可用狀態時,
可以根據用戶設置將INVITE消息刪除、暫時存儲在CPM服務器120中、
或傳送到ISF?130以通過非CPM服務進行消息轉發。但是,圖中沒有示出
此情形。

考慮到接收客戶端的存在和優選、INVITE消息請求的媒體類型、接收
客戶端訂制的服務等等,ISF?130在步驟207中選擇最適合于執行CPM服務
和非CPM服務之間的互配的IWF?140,并在步驟209中將INVITE消息傳送
到選擇的IWF?140。存在是指包括客戶端訂制的服務的類型的信息,以及優
選是指用戶設置,等等。

在步驟211中,在接收到INVITE消息時,IWF?140確定它是否能夠支
持包括在INVITE消息中的并且為之請求會話發起的媒體類型。假定IWF?140
能夠支持請求的媒體類型,則在步驟211中,IWF?140基于適合于非CPM
服務的格式,將接收的INVITE消息轉換成非CPM消息。僅供參考,如下
轉換INVITE消息:當IWF?140可支持的非CPM服務是諸如SIMPLE?IM、
POC等等之類的基于SIP的服務時,INVITE消息中的特定報頭、參數或SDP
體被適配為相應的非CPM消息格式,以及當IWF?140可支持的非CPM服
務是諸如SMS、MMS等等之類的基于非SIP的服務時,INVITE消息被轉
換為適合于相應的非CPM服務的協議的消息格式。

如果請求的媒體類型沒有一個能被IWF?140支持,則IWF?140向ISF?130
發送相應的響應消息(例如,“415?Unsupported?Media?Type(不支持的媒體
類型)”)。在接收到“415?Unsupported?Media?Type”消息時,ISF?130可以根
據服務策略,將該消息經由CPM服務器120傳送到發送CPM客戶端110,
或選擇另一個IWF并重試互配。此外,如果請求的媒體類型中的一些能夠
被IWF?140支持,則在消息轉換過程中忽略對不支持的媒體類型的會話請
求。

在步驟213中,IWF?140向相應的非CPM服務器160傳送轉換后的非
CPM消息,非CPM服務器160又在步驟215中將轉換后的非CPM消息傳
送到接收非CPM客戶端111。在步驟217和219中,非CPM客戶端111響
應于從非CPM服務器160接收到的非CPM消息,將響應消息經由非CPM
服務器160傳送到IWF?140。

在步驟221中,IWF?140將經由非CPM服務器160接收的響應消息轉
換成適合于CPM消息格式的消息,例如根據SIP消息格式的OK消息,然
后在步驟223中將轉換后的響應消息傳送到ISF?130。在步驟225中,ISF?130
將轉換后的響應消息傳送到CPM服務器120。

在步驟227中,CPM服務器120發起與IWF?140的用于允許的媒體類
型的會話,然后在步驟229中向發送CPM客戶端110發送OK消息、對步
驟201中的會話發起消息的響應消息。隨后,在步驟231中,CPM客戶端
發起與CPM服務器120的用于允許的媒體類型的發送/接收的會話。

發明內容

技術問題

但是,傳統的CPM系統中的上述互配操作具有以下問題。當CPM客戶
端110請求的媒體類型中僅僅一些能夠被IWF?140支持時,對于不支持的媒
體類型不執行互配,并因而不能向它們提供CPM服務,如步驟211所述。
由于這引起CPM服務的質量的惡化,因此需要最小化這樣的限制。

技術方案

因此,已經做出本發明以至少解決現有技術中存在的上述問題,并且本
發明提供一種在CPM系統中甚至對于特定的IWF不支持的媒體類型也支持
互配的方法。

此外,本發明提供一種在CPM系統中對于特定的IWF不支持的媒體類
型選擇另一個IWF的方法。

此外,本發明提供一種在CPM系統中用于根據媒體類型發起與不同的
IWF的會話并且控制發起的會話的方法。

此外,本發明提供一種在CPM系統中通過向發起的會話添加新的媒體
來修改根據媒體類型發起的與不同的IWF的會話的方法。

此外,本發明提供一種在CPM系統中通過刪除包括在發起的會話中的
媒體來修改根據媒體類型發起的與不同的IWF的會話的方法。

此外,本發明提供一種在CPM系統中通過刪除包括在發起的會話中的
媒體并且向發起的會話添加新的媒體來修改根據媒體類型發起的與不同的
IWF的會話的方法。

根據本發明的一方面,提供一種在支持訂制融合IP消息(CPM)服務
的第一客戶端和沒有訂制該CPM服務的第二客戶端之間的CPM會話的
CPM服務器中的會話控制方法,該會話控制方法包括:在通過CPM服務器
和互配功能(IWF)在第一客戶端和第二客戶端之間發起該CPM會話之后,
從第一客戶端接收包括特定媒體的會話修改請求消息;通過發起的CPM會
話向IWF發送包括該特定媒體的會話修改請求消息;以及從該IWF接收響
應消息,該響應消息包括對該包括特定媒體的會話修改請求消息的拒絕理
由。

該會話控制方法還可以包括:當包括在該響應消息中的拒絕理由是該特
定媒體不被該IWF支持時,向互配選擇功能(ISF)發送對被拒絕的特定媒
體的會話請求。

根據本發明的另一方面,提供一種在用于支持訂制CPM服務的第一客
戶端和沒有訂制CPM服務的第二客戶端之間的CPM會話的IWF中的會話
控制方法,該會話控制方法包括:在通過CPM服務器和IWF在第一客戶端
和第二客戶端之間發起CPM會話之后,通過CPM服務器從第一客戶端接收
包括特定媒體的會話修改請求消息;以及當該特定媒體不被該IWF支持時,
向CPM服務器發送響應消息,該響應消息包括拒絕理由,該拒絕理由是特
定媒體不被該IWF支持的指示。

根據本發明的另一方面,提供一種用于支持訂制CPM服務的第一客戶
端和沒有訂制CPM服務的第二客戶端之間的CPM會話的互配裝置,該互配
裝置包括:至少一個IWF,用于支持至少一個媒體的每一個,以及當接收到
對不被該IWF支持的媒體的互配請求時,產生拒絕理由,該拒絕理由是相
應媒體不被該IWF支持的指示;和ISF,用于在通過CPM服務器和IWF在
第一客戶端和第二客戶端之間發起CPM會話之后,當通過CPM服務器從第
一客戶端接收到包括特定媒體的會話修改請求消息時,從至少一個IWF當
中選擇負責該特定媒體的互配的實體。

該互配裝置還可以包括控制器,用于當從該IWF接收到作為該特定媒
體不被該IWF支持的指示的拒絕理由時,指令該ISF重新選擇負責該特定媒
體的互配的實體。

根據本發明的另一方面,提供一種在用于支持訂制CPM服務的第一客
戶端和沒有訂制CPM服務的第二客戶端之間的CPM會話的CPM服務器中
的會話控制方法,該會話控制方法包括:從第一客戶端接收包括特定媒體的
會話發起消息;通過ISF向IWF發送包括該特定媒體的會話發起消息;以及
通過該ISF從IWF接收響應消息,該響應消息包括該會話發起消息的拒絕理
由。

該會話控制方法還可以包括:當拒絕理由是該特定媒體不被該IWF支
持時,向該ISF重新發送包括該特定媒體的會話發起消息。

根據本發明的另一方面,提供一種在用于支持訂制CPM服務的第一客
戶端和沒有訂制CPM服務的第二客戶端之間的CPM會話的IWF中的會話
控制方法,該會話控制方法包括步驟:通過CPM服務器從第一客戶端接收
包括特定媒體的會話發起消息;以及當該特定媒體不被該IWF支持時,向
CPM服務器發送響應消息,該響應消息包括拒絕理由,該拒絕理由是特定
媒體不被該IWF支持的指示。

根據本發明的另一方面,提供一種用于支持訂制CPM服務的第一客戶
端和沒有訂制CPM服務的第二客戶端之間的CPM會話的互配裝置,該互配
裝置包括:至少一個IWF,用于支持至少一個媒體的每一個,以及當接收到
對不被該IWF支持的媒體的互配請求時,產生拒絕理由,該拒絕理由是相
應媒體不被該IWF支持的指示;和ISF,用于當通過CPM服務器從第一客
戶端接收到包括該特定媒體的會話發起請求消息時,從至少一個IWF當中
選擇負責該特定媒體的互配的實體。

該互配裝置還可以包括控制器,用于當從該IWF接收到作為該特定媒
體不被該IWF支持的指示的拒絕理由時,指令該ISF重新選擇負責該特定媒
體的互配的實體。

有益效果

具體地,當需要互配時,CPM服務器同時執行接收客戶端訂制的多個
非CPM服務的互配,以使得CPM客戶端能夠通過一個會話交換各種媒體類
型,并且同時非CPM客戶端能夠通過使用各種消息服務與CPM客戶端交換
媒體。因此,能夠增加消息服務的用戶的滿意度。

附圖說明

通過下面結合附圖的詳細描述,本發明的上述和其它目的、特征和優點
將更加明顯,其中:

圖1是示出了CPM系統的實體的圖;

圖2是用于說明用于在CPM服務和非CPM服務之間互配的消息發送/
接收的消息流程圖;

圖3和4是用于說明根據本發明的第一實施例的在CPM系統的代理模
式中發起會話的操作的消息流程圖;

圖5是示出了根據本發明的第一實施例的在代理模式中IWF的操作的
流程圖;

圖6是示出了根據本發明的第一實施例的在代理模式中CPM服務器的
操作的流程圖;

圖7和8是用于說明根據本發明的第二實施例的在代理模式中向已經發
起的會話添加新的媒體類型的操作的消息流程圖;

圖9是用于說明根據本發明的第三實施例的在代理模式中通過從已經發
起的會話中刪除特定媒體類型來修改已經發起的會話的操作的消息流程圖;

圖10和11是用于說明根據本發明的第四實施例的在代理模式中通過向
已經發起的會話添加新的媒體類型同時從已經發起的會話中刪除現有媒體
類型來修改已經發起的會話的操作的消息流程圖;

圖12是示出了根據本發明的第二到第四實施例的在代理模式中接收會
話修改請求的CPM服務器的操作的流程圖;

圖13和14是示出了根據本發明的第二到第四實施例的在代理模式中從
IWF接收響應消息的CPM服務器的操作的流程圖;

圖15和16是用于說明根據本發明的第五實施例的在CPM系統的
B2BUA模式中發起會話的操作的消息流程圖;

圖17和18是用于說明根據本發明的第六實施例的在B2BUA模式中通
過改變特定媒體類型來修改已經發起的會話的操作的消息流程圖;

圖19和20是用于說明根據本發明的第一實施例的當ISF工作在其中不
允許修改消息體部分的代理模式中時發起會話的另一個操作的消息流程圖;

圖21和22是用于說明根據本發明的第五實施例的當ISF工作在B2BUA
模式中時發起會話的另一個操作的消息流程圖;和

圖23和24是用于說明根據本發明的第二實施例的當IWF工作在代理
模式中時向已經發起的會話添加新的媒體的操作的消息流程圖。

具體實施方式

在下文中,將參考附圖描述本發明的實施例。應當注意,雖然在不同的
附圖中,但是相似的組件由相似的參考數字指定。此外,在下面的描述中,
當對合并于此的已知功能和配置的詳細描述可能混淆本發明的主題時,將略
去該詳細描述。此外,應當注意,將僅僅描述對理解根據本發明的操作是必
要的部分,而省略除了該必要部分之外的部分的描述,以便不致混淆本發明
的要點。

在給出本發明的描述之前,將詳細描述將要應用在本發明的融合IP消
息(CPM)系統中的互配選擇功能(ISF)和互配功能(IWF)。

在本發明中,根據CPM系統的實施環境,ISF可以包括在CPM服務器
或IWF中,或可以被實現為獨立的實體。可替換地,ISF和IWF可以被實
現為單個設備。

此外,ISF可以根據CPM系統的消息處理方案工作在代理模式或背對背
用戶代理(B2BUA)模式中。

在代理模式中,ISF的主要操作包括IWF選擇、消息傳送等等。消息傳
送是指將從CPM服務器接收到的消息傳送到選擇的IWF、將從IWF接收到
的響應消息傳送到CPM服務器的操作等等。此外,當傳送接收的消息時,
可以允許ISF修改接收的消息的特定報頭字段或參數。但是,一般不允許修
改消息體部分。然而,由于可能出現根據CPM系統的設計甚至在代理模式
中也可以修改消息體部分的例外情況,所以本發明提出ISF將對于兩種情況
的每一個不同地操作。但是,在允許修改消息體部分的代理模式情況下,IWF
不位于發起的會話上,因而通過發起的會話傳送的媒體不經過IWF。

在B2BUA模式中,ISF的主要操作包括IWF選擇,另外包括充當用于
CPM服務器的IWF或用作用于IWF的CPM服務器的用戶代理(UA)。UA
如下工作:當ISF從CPM服務器接收到任何消息時,UA產生與其對應的新
消息,并且向CPM服務器發送產生的消息。因而,對于IWF,ISF充當CPM
服務器的UA。當ISF從IWF接收到任何消息時,ISF產生與其對應的新消
息,并且向CPM服務器發送產生的消息。因而,對于CPM服務器,ISF充
當IWF的UA。在B2BUA模式中,ISF能夠通過以這種方式用作UA來控
制通過會話傳送的媒體流。此外,在B2BUA模式中,ISF位于發起的會話
上,因而通過發起的會話傳送的媒體經過IWF。

根據CPM系統的實施,可以為每個非CPM服務提供用于控制與一個指
定的非CPM服務的互配的單獨的IWF,或者一個IWF可以控制與所有非
CPM服務或多個非CPM服務的互配。在說明書中,將在網絡環境中為每個
非CPM服務提供單獨的IWF的假定之下描述本發明的實施例。

首先,將描述根據本發明的實施例的初始會話發起。

CPM客戶端向CPM服務器發送對媒體的會話請求。當需要互配時,CPM
服務器向ISF傳送會話請求,并且ISF選擇合適的IWF并向選擇的IWF傳
送會話請求。IWF確定是否允許會話請求并發送對會話請求的響應。當IWF
拒絕會話請求時,IWF在響應中包括拒絕的細節。

如果會話請求的拒絕理由是接收客戶端給出會話請求的拒絕通知,則被
拒絕的會話不需要被再次請求。這是因為即使當另一個IWF支持為之做出
會話請求的媒體時,客戶端方也將再次拒絕該會話請求。但是,如果會話請
求的拒絕理由是IWF不能支持為之做出會話請求的媒體,則可以通過向支
持該媒體的另一個IWF轉發該會話請求來發起會話。

因此,如果IWF在對會話請求的響應中包括拒絕的細節,即關于拒絕
者或拒絕理由的信息,則可以根據拒絕的細節確定是否轉發被拒絕的會話。
當CPM客戶端發送對多個媒體的會話請求并且請求的媒體中的一些被拒絕
時,拒絕的細節包括關于被拒絕的媒體的信息。例如,由CPM服務器或ISF
確定是否轉發會話請求。

接著,將描述根據本發明的實施例的會話修改。會話修改可以基本上被
分成向會話添加新的媒體、刪除包括在會話中的媒體、從會話中刪除現有媒
體且向會話添加新的媒體、改變現有媒體類型,等等。在此情況下,不做出
會話發起請求并且做出會話修改請求。當IWF拒絕對添加新的媒體的會話
請求時,IWF發送包括拒絕的細節的響應,并且CPM服務器通過考慮拒絕
的細節確定如何修改會話。下面將詳細描述。

本發明可以在“代理模式”和“B2BUA模式”中實施,并且現在將基
于本發明的主要構思描述本發明的實施例。

在本發明的第一實施例中,將參考圖3到6和19到20討論在代理模式
中發起對于多個媒體的初始會話的操作。

在本發明的第二實施例中,將參考圖7到8和23到24討論在代理模式
中通過向已經發起的會話添加新的媒體類型來修改已經發起的會話的操作。

在本發明的第三實施例中,將參考圖9討論在代理模式中通過從已經發
起的會話中刪除特定媒體類型來修改已經發起的會話的操作。

在本發明的第四實施例中,將參考圖10到11討論通過改變特定媒體類
型來修改已經發起的會話的操作。

在本發明的第五實施例中,將參考15到16和21到22討論在B2BUA
模式中發起對于多個媒體的初始會話的操作。

在本發明的第六實施例中,將參考圖17到18討論在B2BUA模式中通
過改變特定媒體類型來修改已經發起的會話的操作。

ISF:代理模式

A.不允許修改消息體部分的情況

圖3和4示出了根據本發明的第一實施例的當ISF工作在不允許修改消
息體部分的代理模式中時發起會話的操作。圖3和4中的操作假定以下條件:

(1)CPM客戶端110發起包括第一和第二媒體的會話。

(2)接收客戶端是非CPM客戶端,并且訂制第一、第二和第三非CPM
服務。

(3)第一IWF?141執行與第一非CPM服務的互配,第二IWF?142執行
與第二非CPM服務的互配,以及第三IWF?143執行與第三非CPM服務的
互配。

(4)第一媒體被第一非CPM服務支持,但是第二媒體不被第一非CPM
服務支持。這對第一IWF?141是一樣的。

(5)第二媒體被第二非CPM服務支持,但是第一媒體不被第二非CPM
服務支持。這對第二IWF?142是一樣的。

(6)第一和第二媒體二者都不被第三非CPM服務支持。這對第三IWF
143是一樣的。

在圖3中,省略從每個IWF到接收非CPM客戶端的會話發起請求和其
響應的傳送。

在步驟301中,CPM客戶端110向CPM服務器120發送會話發起請求
消息(INVITE)。在步驟303中,在接收到會話發起請求消息時,CPM服務
器120確定對于該會話發起是否需要互配。圖3,由于接收客戶端是非CPM
客戶端,因此需要互配。因而,在步驟305中,CPM服務器120向ISF?130
發送會話發起請求消息。

在步驟307中,ISF?130基于包括接收客戶端的優選項和存在、為之做
出會話發起請求的媒體類型、接收客戶端訂制的服務、服務策略等的信息,
選擇最適合于執行會話發起的IWF。假定ISF?130在步驟307中選擇第三IWF
143。

在步驟309中,ISF?130向第三IWF?143傳送會話發起請求消息。在步
驟311中,因為第三IWF?143不支持第一和第二媒體,所以第三IWF?143產
生并發送回對會話發起請求消息的拒絕響應消息。在步驟313中,ISF?130
將接收的拒絕響應消息傳送到CPM服務器120。拒絕響應消息包括拒絕的
細節,例如關于拒絕的一個或多個理由、拒絕者和被拒絕的媒體的信息。

特定的代號可以用來在拒絕響應消息中包括拒絕的細節。所有SIP響應
消息包括可以根據處理與每個響應消息對應的SIP請求消息的結果而變化的
唯一代號、錯誤的理由,等等。例如,當諸如會話發起請求或媒體添加請求
之類的SIP請求消息被IWF拒絕時,代號“488”可以包括在相應的響應消
息中,以及當SIP請求消息被接收客戶端拒絕時,代號“606”可以包括在
相應的響應消息中。這些代號僅僅是說明性的,并且代號可以根據系統實施
而變化。但是,可能發生CPM服務器120僅僅由代號不能準確確定的情況。
這是做出對支持多個媒體類型的會話的發起的請求、但是多個媒體中的一些
被用戶拒絕并且它們中的一些被IWF拒絕的情況。在這種情況下,響應消
息必須直接或間接地澄清對于每一個被拒絕的媒體的拒絕細節。下面將在表
1和3中描述澄清每一個媒體的拒絕細節的拒絕響應消息的格式。

在步驟315中,CPM服務器120可以從拒絕響應消息的代號知道會話
請求被IWF拒絕,并且檢查是否允許重試發起被拒絕的會話。在圖3中,
假定允許重試做出會話發起請求。因而,在步驟317中,CPM服務器120
向ISF?130發送會話發起請求消息以便重試會話發起。

在步驟319中,ISF?130選擇合適的IWF。當然,不選擇已經發送回對
先前會話請求的拒絕響應消息的IWF,即第三IWF?143。在步驟319中,假
定ISF?130選擇第一IWF?141。因而,在步驟321中,ISF?130向第一IWF?141
傳送會話發起請求消息。

由于假定第一媒體被第一IWF?141支持并且第二媒體不被第一IWF?141
支持,因此第一IWF?141可以接受對于第一媒體的會話的發起。因而,在步
驟323中,第一IWF?141產生并發送回接受響應消息(200?OK)。由于第二
媒體被第一IWF?141拒絕,因此根據配置對會話發起請求的部分接受響應消
息的方法,第一IWF?141在響應消息中包括指示第二媒體被第一IWF?141拒
絕的信息,如下所述。

在步驟325中,ISF?130將接收的響應消息傳送到CPM服務器120。在
步驟327中,在CPM服務器120和第一IWF?141之間發起包括第一媒體的
會話。

在步驟329中,CPM服務器120產生對于被第一IWF?141拒絕的第二
媒體的會話發起請求消息,然后在步驟331中,向ISF?130發送產生的消息。
在步驟333中,ISF?130選擇最適合于執行請求的會話發起的IWF。當然,
ISF?130不選擇已經發送回對包括第二媒體的先前會話請求的拒絕響應消息
的第一IWF?141。

在步驟333中,假定ISF?130選擇第二IWF?142。因而,在步驟335中,
ISF?130向第二IWF?142發送會話發起請求消息。在步驟337中,第二IWF?142
產生并發送回對會話發起請求消息的接受響應消息(200?OK)。在步驟339
中,ISF?130將接收的響應消息傳送到CPM服務器120。隨后,在步驟341
中,在CPM服務器120和第二IWF?142之間發起包括第二媒體的會話。

在步驟343中,CPM服務器120產生對在步驟301中接收的會話發起
請求消息的響應消息,并且將產生的響應消息發送回CPM客戶端110。此
響應消息包括如下指示:包括第一媒體的會話和包括第二媒體的會話被全部
接受。隨后,在步驟345中,在CPM客戶端110和CPM服務器120之間發
起包括第一和第二媒體的會話。

在圖3和4中,ISF?130和第一到第三IWF?141、142、143可以實現為
單個互配單元。這樣的單個互配單元包括控制器(圖中未示出)。在此設備
配置情況下,ISF?130可以接收包括第一和第二媒體的會話發起請求消息
(INVITE),并且選擇負責第一和第二媒體的互配的IWF。如果ISF?130選
擇第三IWF?143,則ISF?130向第三IWF?143發送媒體發起請求消息。如上
所述,第三IWF?143不能支持第一和第二媒體。因而,第三IWF?143向控制
器(未示出)傳送拒絕的細節,指示第一和第二媒體由于第三IWF?143的屬
性而被拒絕。基于此拒絕理由,控制器指令ISF?130重新選擇用于第一和第
二媒體的IWF,并且ISF?130可以根據控制器的指令重新選擇IWF。作為另
一個示例,控制器可以被設計為基于拒絕理由重新選擇IWF。

圖19和20示出了根據本發明的第一實施例的當ISF工作在不允許修改
消息體部分的代理模式中時發起會話的操作。

比較圖19和20的操作與圖3和4的操作,這兩個操作的不同之處在于,
圖3和4中的CPM服務器120從第一IWF?141和第二IWF?142接收所有響
應消息,然后組合接收的響應消息以向CPM客戶端110發送組合后的響應
消息,但是圖19和20中的CPM服務器120單獨地處理從各個IWF接收到
的響應消息。也就是說,在圖19和20中,CPM服務器120基于從主要執
行互配的IWF(即第一IWF?141)接收到的響應消息,首先發起與CPM客
戶端110的會話。當CPM服務器120從次要執行互配的IWF(即,第二IWF
142)接收到接受響應消息時,CPM服務器120將第二IWF?142另外接受的
媒體添加到在CPM服務器120和CPM客戶端110之間已經發起的會話。此
外,圖19和20的操作假定與圖3和4的操作相同的條件,除了接收客戶端
不訂制第三非CPM服務之外。因此,除上述差別之外,圖19和20的操作
基本上與圖3和4的相同。現在將描述圖19和20的操作。

在步驟1301中,CPM客戶端110向CPM服務器120發送會話發起請
求消息(INVITE)。在步驟1303中,在接收到會話發起請求消息時,CPM
服務器120確定對于該會話發起是否需要互配。在圖19和20,由于接收客
戶端是非CPM客戶端,因此需要互配。因而,在步驟1305中,CPM服務
器120向ISF?130發送會話發起請求消息。

在步驟1307中,ISF?130基于包括接收客戶端的優選項和存在、為之做
出會話發起請求的媒體類型、接收客戶端訂制的服務、服務策略等的信息,
選擇最適合于執行會話發起的IWF。假定ISF?130在步驟1307中選擇第一
IWF?141。

在步驟1309中,ISF?130向第一IWF?143傳送會話發起請求消息。在步
驟1311中,第一IWF?141產生并發送回“200?OK”作為對會話發起請求消
息的響應消息,因為第一IWF?141支持第一媒體。在步驟1313中,ISF?130
將接收的響應消息傳送到CPM服務器120。在步驟1311中,第一IWF?141
在響應消息中包括指示第一媒體被接收方用戶接受并且第二媒體不被IWF
支持因而被自動拒絕的細節。

在步驟1315中,在CPM服務器120和第一IWF?141之間發起用于接受
的第一媒體的會話。在步驟1317中,CPM服務器120創建對于被拒絕的第
二媒體的新的會話發起請求,然后在步驟1317中,向ISF?130發送創建的請
求。在步驟1315中,可以根據CPM服務器120的操作方案在步驟1317之
后發起第一媒體會話。

在步驟1321中,CPM服務器120向CPM客戶端110發送“200?OK”
作為對在步驟1301中接收的會話發起請求的響應消息。響應消息可以包括
第一媒體被接受并且第二媒體被拒絕的簡單指示。在步驟1321中響應消息
被傳送到CPM客戶端110的實際的時間點可以根據CPM服務器120的操作
方案而變化。換句話說,CPM服務器120可以等待特定時間段以接收對在
步驟1319中發送的新的會話發起請求的響應消息,或者可以一從ISF?130
接收到第一響應消息就向CPM客戶端110發送響應消息。圖19和20假定
后者。在前者情況下,當在固定的時間段期間接收到對新的會話發起請求的
響應消息時,CPM服務器120集成這些響應消息,然后向CPM客戶端110
發送最終的響應消息,如圖3和4的操作中所示。如果在該固定的時間段之
外接收到對新的會話發起請求的響應消息,則CPM服務器120首先向CPM
客戶端110發送首先接收到的響應消息以發起對于被接受的媒體的會話,然
后根據隨后的對新的會話發起請求的響應消息的內容修改或保持發起的會
話。

在步驟1323中,在CPM客戶端110和CPM服務器120之間發起第一
媒體會話。

在步驟1325中,ISF?130選擇最適合于執行接收的新的會話發起請求的
IWF,并向選擇的IWF發送該會話發起請求。在圖20中,假定ISF?130選
擇第二IWF?412。在步驟1327中,ISF?130向第二IWF?142發送會話發起請
求消息。在步驟1329中,第二IWF?142產生并發送回“200?OK”作為對會
話發起請求消息的響應消息,因為它支持第二媒體。在步驟1331中,ISF?130
將接收的響應消息傳送到CPM服務器120。

在步驟1333中,在CPM服務器120和第二IWF?142之間發起第二媒體
會話。

在步驟1335中,CPM服務器120向CPM客戶端110發送會話修改請
求。會話修改請求是用于向在CPM客戶端110和CPM服務器120之間發起
的第一媒體會話添加第二媒體會話的請求。

在步驟1337中,CPM客戶端110向CPM服務器120發送“200?OK”
作為對會話修改請求的接受響應消息。在步驟1339中,以包括第一和第二
媒體二者的方式修改在CPM客戶端110和CPM服務器120之間發起的會話。

圖5示出了根據本發明的第一實施例的在代理模式中IWF的操作。在
此操作中,IWF執行發送回對會話發起請求的響應消息的操作。

在步驟401中,IWF檢查會話發起請求是否被拒絕,并且當會話發起請
求被拒絕時進行到步驟403。在步驟403中,由于會話發起請求被拒絕,因
此IWF產生拒絕響應消息,并且將產生的拒絕響應消息發送回ISF。經由
IWF,將發送回的響應消息發送給CPM服務器。IWF根據拒絕理由產生在
[RFC(Request?for?Comments)3261]中定義的拒絕響應消息。如果在步驟401
中會話發起請求被接受(即不被拒絕),則IWF進行到步驟405。在步驟405
中,IWF對于請求的媒體的全部或一些,檢查會話是否被接受。當僅僅對于
請求的媒體中的一些,該會話被接受時,IWF進行到步驟407。

在步驟407中,IWF產生接受響應消息(200?OK),然后將產生的接受
響應消息發送回ISF。關于這一點,IWF在響應消息中包括澄清被拒絕的媒
體類型是否被IWF或接收客戶端拒絕的信息。下面將描述在響應消息中表
達這樣的信息的方式。

當在步驟405中對于請求的媒體的全部,會話被接受時,IWF進行到步
驟409,并產生接受響應消息(200?OK),以然后將產生的接受響應消息發
送回ISF。

當在步驟407中請求的媒體中的一些被拒絕時,IWF在響應消息中包括
拒絕理由。在本發明中,對于媒體的會話發起請求的拒絕理由分成兩類。第
一類別對應于通過從接收客戶端給出的通知拒絕請求的情況,以及第二類別
對應于IWF拒絕不支持的媒體的情況。在本發明中,IWF在響應消息中包
括媒體的拒絕理由,從而使得可以重試發起對于被拒絕的媒體類型的會話。

作為在響應消息中包括關于對于媒體的會話發起為什么被拒絕或被誰
拒絕的信息的方式,在本發明中提出了三種情況。

在表1中描述情況1。

表1


在情況1中,定義“rejected-by”SDP屬性以表達關于對于媒體的會話
發起為什么被拒絕或者被誰拒絕的信息。表示媒體級別的屬性的
“rejected-by”具有拒絕對于相應的媒體類型的會話發起的拒絕者的標識符
值。在本發明中,“user”或“network”被示出為屬性值。在實際實施中,
屬性值可以改變為另一個值或由另一個值替代。屬性值“user”表示接收客
戶端拒絕對于媒體的會話發起請求的情況,以及屬性值“network”表示接收
客戶端的IWF或非CPM服務器拒絕對于媒體的會話發起請求因為它不能支
持相應的媒體的情況。

從表1可以看出,視頻無論如何都被拒絕,因為視頻的媒體線中的端口
號(m=video?0?RTP/AVP?98?99)被設置為0。從屬性值“rejected-by”被設
置為“network”的事實,也可以看出,請求的媒體類型不被IWF支持,因
而IWF拒絕會話請求。

除了會話發起請求之外,可以由IWF以對于將新的媒體添加到已經發
起的會話的請求相同的方式執行澄清關于媒體類型為什么被拒絕或者被誰
拒絕的信息的上述操作。

在表2中描述情況2。

表2


在情況2中,IWF在響應消息中表達它的支持的媒體類型。為此,IWF
在響應消息中包括[RFC?3840]媒體特征標簽當中的它的支持的媒體的特征
標簽。在表2中,由于IWF支持音頻和視頻媒體,因此它在“Contact”報
頭中包括音頻和視頻標簽。

當根據情況2產生的響應消息包括與被拒絕了會話發起的媒體類型對應
的媒體標簽時,相應的媒體被認為是被接收客戶端拒絕。但是,當響應消息
不包括與被拒絕的媒體類型對應的媒體標簽時,相應的媒體被認為是被IWF
拒絕。

在表3中描述情況3。

表3


在情況3中,IWF在響應消息中包括作為SDP參數的支持的媒體信息。
通過使用SDP參數來傳送SIP?UA能力信息的方法在[RFC?3264]中定義。由
于IWF通過使用SDP參數傳送關于它的支持的媒體類型的信息,因此響應
消息包括兩個SDP體。

SDP模式之一是用于表示會話發起請求的接受或拒絕的SDP體(SDP
應答),以及另一個是包括關于IWF支持的媒體的信息的SDP體。為了將后
者與前者區分開來,在本發明中,“capability”被定義為后者的
“Content-Disposition”報頭值。“capability”指示相應的SDP體不表示SDP?
Answer,而是SIPUA的能力信息。

在表3中,SDP體部分,其“Content-Disposition”報頭值被設置為
“capability”,表示IWF的能力。在表3中,與IWF的能力對應的SDP體
表示視頻和音頻媒體被IWF支持的事實、每一個媒體可支持的編解碼器信
息等等。

當在根據情況3產生的響應消息中拒絕IWF支持的媒體類型時,該媒
體類型被認為是被接收客戶端拒絕。但是,當不被IWF支持的媒體類型被
拒絕時,該媒體類型被認為是被IWF拒絕。

圖6示出了如圖3和4所述當ISF工作在根據本發明的第一實施例的不
允許修改消息體部分的代理模式中時CPM服務器的操作。

根據傳統的技術,在從CPM客戶端接收到會話發起請求消息時,CPM
服務器確定是否需要執行互配,然后當需要執行互配時,向ISF發送會話發
起請求消息。也就是說,當不需要互配時,CPM服務器向接收客戶端的地
址發送會話發起請求消息,以及當需要互配時,經由ISF向相應的IWF發送
會話發起請求消息。

在本發明的第一實施例中,CPM服務器用和傳統的技術相同的方式工
作以便處理會話發起請求消息。但是,CPM服務器和傳統的技術的工作方
式不同之處在于,它從ISF接收對會話發起請求消息的響應消息。也就是說,
當在為其請求會話發起的媒體當中存在被IWF拒絕的媒體時,CPM服務器
根據包括在響應消息中的拒絕的細節重試發起對于被拒絕的媒體的會話。

在步驟501中,CPM服務器從ISF接收對會話發起請求消息的響應消息。
在步驟503中,當響應消息是接受響應消息(200?OK)時,CPM服務器進
行到步驟505,并且與ISF發起包括被接受的媒體的會話。在步驟507中,
CPM確定在為其請求會話發起的媒體類型當中是否存在由于IWF的屬性而
被拒絕的媒體類型,即不被IWF支持的媒體類型。當存在被拒絕的媒體類
型時,CPM服務器進行到步驟511,以及當不存在被拒絕的媒體類型時,進
行到步驟509。

不存在由于IWF的屬性而被拒絕的媒體類型的情況與所有請求的媒體
類型都被接受的情況,或一些媒體類型被接收客戶端拒絕的情況對應。因而,
在步驟509中,CPM服務器120產生對會話發起請求消息的響應消息,并
且將產生的響應消息發送回已經發送了該會話發起請求消息的CPM客戶
端。

在步驟511中,CPM服務器重新產生對于由于IWF的屬性被拒絕的媒
體類型的會話發起請求消息(INVITE)。在步驟513中,CPM服務器向ISF
發送重新產生的會話發起請求消息,并且返回到步驟501,在步驟501中CPM
服務器再次從ISF接收對會話發起請求消息的響應消息。

如果在步驟503中不接受會話發起請求,則CPM服務器進行到步驟515,
并檢查會話發起請求是否被接收客戶端拒絕。當會話發起請求被接收客戶端
拒絕時,CPM服務器進行到步驟509,以及當會話發起請求不被接收客戶端
拒絕時,進行到步驟517。

在步驟517中,CPM服務器通過預定義的代號發現會話發起請求的拒
絕理由,從而檢查是否可以重試會話發起請求。考慮會話發起請求的拒絕理
由來確定是否可以重試會話發起請求。此外,CPM服務器可以依據服務策
略、是否超過受限的重試次數等等,考慮是否允許重試會話發起請求。如果
允許重試會話發起請求,則CPM服務器進行到步驟513,并向ISF重新發
送對于被拒絕的媒體的會話發起請求消息。但是,如果不允許重試會話發起
請求,則CPM服務器進行到步驟509,并且將響應消息發送回CPM客戶端。

在通過互配在CPM客戶端和CPM服務器之間發起會話之后,應CPM
客戶端的請求必須修改會話。在下文中,將描述根據本發明的實施例的修改
已經發起的會話的操作。

會話修改包括(1)向已經發起的會話添加新的媒體,其將被描述為圖7
和8中的本發明的第二實施例;(2)刪除包括在已經發起的會話中的媒體,
其將被描述為圖9中的本發明的第三實施例;和(3)改變已經發起的會話
的媒體類型,即刪除現有媒體同時添加新的媒體,其將被描述為圖10和11
中的本發明的第四實施例。

CPM客戶端通過向CPM服務器發送會話修改請求消息來請求CPM服
務器修改會話。根據上述三種情形,會話修改請求消息在情況(1)下可以
被格式轉換為媒體添加請求消息、在情況(2)下可以被格式轉換為媒體刪
除請求消息、以及在情況(3)下可以被格式轉換為媒體改變請求消息。

圖7和8示出了根據本發明的第二實施例的當ISF工作在不允許修改消
息體部分的代理模式中時向已經發起的會話添加新的媒體類型的操作。圖7
和8中的操作假定以下條件:

(1)在CPM客戶端和CPM服務器之間發起包括第一和第二媒體的會
話。

(2)為了向/從接收客戶端發送/接收第一媒體,CPM服務器已經發起
了與第一IWF的包括第一媒體的會話。

(3)為了向/從接收客戶端發送/接收第二媒體,CPM服務器已經發起
了與第二IWF的包括第二媒體的會話。

(4)第一和第二IWF不支持第三媒體。此外,第一IWF支持第四媒體。

(5)第三IWF支持第三媒體,以及執行與第三非CPM服務的互配。

(6)接收客戶端訂制支持第三媒體的第三非CPM服務。

在步驟601中,CPM客戶端110發送用于向在CPM客戶端110和CPM
服務器120之間發起的(第一媒體+第二媒體)會話添加第三和第四媒體的
媒體添加請求消息。媒體添加請求消息包括用于第一、第二、第三和第四媒
體的SDP參數。

在步驟603中,與在CPM客戶端10和CPM服務器120之間發起的(第
一媒體+第二媒體)會話連接的媒體會話是在CPM服務器120和第一IWF
141之間發起的第一媒體會話和在CPM服務器120和第二IWF?412之間發
起的第二媒體會話。

在步驟603中,CPM服務器120選擇第一媒體會話和第二媒體會話中
的一個。在步驟603中,假定CPM服務器120選擇第一媒體會話。在步驟
605中,CPM服務器120向與第一媒體會話連接的第一IWF?141發送媒體添
加請求消息(Re-INVITE)。媒體添加請求消息包括用于第一、第三和第四媒
體的SDP參數。

在步驟607中,第一IWF?141接受包括在媒體添加請求消息中的第一和
第四媒體,但是拒絕第三媒體,因為第一IWF?141不能支持第三媒體。因而,
第一IWF?141將包括這樣的細節的響應消息(200?OK)發送回CPM服務器
120。對于此,響應消息的細節包括指示第三媒體由于第一IWF?141的屬性
而被拒絕的信息。在步驟609中,以包括第一和第四媒體的方式修改在CPM
服務器120和第一IWF?141之間發起的會話。

在步驟611中,CPM服務器120重試對由于第一IWF?141的屬性而被
拒絕的第三媒體的媒體添加請求。也就是說,CPM服務器120試著向任何
還沒有嘗試媒體添加請求的第二會話添加第三媒體。為此,在步驟613中,
CPM服務器120產生用于向第二會話添加第三媒體的媒體添加請求消息
(Re-INVITE),并且向第二IWF?142發送產生的媒體添加請求消息。媒體
添加請求消息包括用于第二和第三媒體的SDP參數。

在步驟615中,第二IWF?142接受包括在媒體添加請求消息中的第二媒
體,因為第二媒體包括在現有會話中,但是拒絕第三媒體,因為它不能支持
第三媒體。因而,在步驟617中,第二IWF?142產生并發送回包括這樣的細
節的響應消息(200?OK)。對于此,響應消息的細節包括指示第三媒體由于
第二IWF?142的屬性而被拒絕的信息。

在步驟617中,由于不存在可以向其添加被第一和第二IWF?141、142
拒絕的第三媒體的會話,因此CPM服務器120產生對于第三媒體的會話發
起請求消息,并且在步驟619中確定對于產生的會話發起請求消息是否需要
互配。假定需要互配,在步驟621中,CPM服務器120向ISF?130發送會話
發起請求消息。

在步驟623中,ISF?130選擇最適合于處理會話發起請求消息的IWF。
假定選擇了第三IWF?413,則在步驟625中ISF?130向第三IWF?413發送會
話發起請求消息,以及在步驟627中第三IWF?413產生并發送回接受響應消
息。在步驟629中,ISF?130將響應消息傳送到CPM服務器120。在步驟631
中,在CPM服務器120和第三IWF?143之間發起包括第三媒體的會話。在
步驟633中,CPM服務器120產生對媒體添加請求消息的響應消息,然后
將產生的響應消息發送回CPM客戶端110。在步驟635中,以包括第一、
第二、第三和第四媒體的方式修改在CPM客戶端110和CPM服務器120
之間發起的現有會話。

在圖7和8中,ISF?130和第一到第三IWF?141、142、143可以被實現
為單個互配單元。這樣的單個互配單元包括控制器(圖中未示出)。在此設
備配置情況下,ISF?130可以從CPM服務器120接收用于添加第三和第四媒
體的媒體添加請求消息,并且選擇用于控制請求的第三和第四媒體的互配的
IWF。如果ISF?130選擇第一IWF?141,則它向第一IWF?141發送媒體添加
請求消息。如上所述,第一IWF?141不能支持第三媒體。因而,第一IWF?141
向控制器(未示出)傳送指示第三媒體由于第一IWF?141的屬性而被拒絕的
細節。基于此拒絕理由,控制器指令ISF?130重新選擇用于第三媒體的IWF,
并且ISF?130可以根據控制器的指令重新選擇IWF。作為另一個示例,控制
器可以被設計為基于拒絕理由重新選擇IWF。

在上述操作中,即使當在步驟603中CPM服務器120發起與多個IWF
的媒體會話時,CPM服務器120也重復向任何一個IWF發送媒體添加請求
消息。但是,根據CPM服務器120的操作方案,CPM服務器120可以向各
個IWF(每個發起與CPM服務器120的媒體會話)同時發送媒體添加請求
消息。但是,這可能引起對同一媒體的添加請求同時被不同的IWF接受的
情況,因此CPM服務器120必須通過檢查全部接收的響應消息來防止同一
媒體同時被不同的IWF添加。

因此,作為防止同一媒體的重疊添加的方式,CPM服務器120可以等
到從向其發送了媒體添加請求的所有IWF接收到響應消息為止,以便防止
同一媒體同時被不同的IWF添加。可替換地,CPM服務器120可以通過處
理首先從一個IWF接收到的OK響應消息、當由稍后從另一個IWF接收到
的OK響應消息引起同一媒體的重疊添加時產生會話終止請求消息(BYE)
或媒體刪除請求消息(Re-INVITE)、然后將產生的消息發送到相應的IWF,
來防止同一媒體的重疊添加。

圖23和24示出了根據本發明的第二實施例的當ISF工作在不允許修改
消息體部分的代理模式中時向已經發起的會話添加新的媒體類型的操作。圖
23和24的操作與圖7和8的不同之處在于,CPM服務器試著同時向所有相
關的IWF發送媒體添加請求。

除以下條件之外,圖23和24的操作與圖7和8假定相同的條件:

(1)第一IWF和第二IWF不支持第三媒體。

(2)第一IWF和第二IWF支持第四媒體。

在步驟1501中,CPM客戶端110發送用于向在CPM客戶端110和CPM
服務器120之間發起的(第一媒體+第二媒體)會話添加第三和第四媒體的
媒體添加請求消息。媒體添加請求消息包括用于第一、第二、第三和第四媒
體的SDP參數。

在步驟1503中,與在CPM客戶端10和CPM服務器120之間發起的(第
一媒體+第二媒體)會話連接的媒體會話是在CPM服務器120和第一IWF
141之間發起的第一媒體會話和在CPM服務器120和第二IWF?412之間發
起的第二媒體會話。

在步驟1503中,CPM服務器120向與第一媒體會話連接的第一IWF?141
發送媒體添加請求消息(Re-INVITE)。媒體添加請求消息包括用于第一、第
三和第四媒體的SDP參數。

在步驟1505中,CPM服務器120向與第二媒體會話連接的第二IWF?142
發送媒體添加請求消息(Re-INVITE)。媒體添加請求消息包括用于第二、第
三和第四媒體的SDP參數。

在步驟1507中,第一IWF?141接受包括在媒體添加請求消息中的第一
和第四媒體,但是拒絕第三媒體,因為第一IWF?141不能支持第三媒體。因
而,第一IWF?141將包括這樣的細節的響應消息(200?OK)發送回CPM服
務器120。對于此,響應消息的細節包括指示第三媒體由于第一IWF?141的
屬性而被拒絕的信息。在步驟1509中,以包括第一和第四媒體的方式修改
在CPM服務器120和第一IWF?141之間發起的會話。

在步驟1511中,第二IWF?142接受包括在媒體添加請求消息中的第二
和第四媒體,但是拒絕第三媒體,因為它不能支持第三媒體。因而,在步驟
1513中,第二IWF?142產生并發送回包括這樣的細節的響應消息(200?OK)。
對于此,響應消息的細節包括指示第三媒體由于第二IWF?142的屬性而被拒
絕的信息。在步驟1513中,以包括第二和第四媒體的方式修改在CPM服務
器120和第二IWF?142之間發起的會話。

作為執行上述步驟的結果,同時將第三媒體添加到第一IWF?141和第二
IWF?142。因而,為了防止第三媒體的重疊添加,CPM服務器120產生用于
刪除后來添加的第三媒體的媒體刪除請求消息(Re-INVITE),并向第二IWF
142發送產生的媒體刪除請求消息。

在步驟1517中,響應于媒體刪除請求消息,第二IWF?142向CPM服務
器120發送接受響應消息。在步驟1519中,修改在CPM服務器120和第二
IWF?142之間發起的會話以使得從該會話中刪除第三媒體,并且僅僅第二媒
體包括在該會話中。

將省略后面的步驟的描述,因為已經在圖7和8中描述過了它們。

但是,如圖23和24所述的CPM服務器120的操作可以根據CPM服務
器120的實施稍微有變化。例如,在圖23和24中,CPM服務器120從第
一IWF?141和第二IWF?142接收響應消息,但是CPM服務器120可以根據
服務器的實施方案或設置發送SIP?UPDATE消息或SIP?CANCEL消息,只要
它已經從第一IWF?141接收到OK響應消息但是還沒有從第二IWF?142接收
到響應消息。

當要被添加的所有媒體被第一IWF?141接受時,發送SIP?CANCEL消息,
并且SIP?CANCEL消息用來取消發送給第二IWF?142的媒體添加請求消息。

當請求被添加到第一IWF?141的媒體中的僅僅一些被接受而其它的被
拒絕時,可以使用SIP?UPDATE消息,并且SIP?UPDATE消息用來從發送給
第二IWF?142的媒體添加請求消息中刪除被第一IWF?141接受的媒體。

圖9示出了根據本發明的第三實施例的當ISF工作在不允許修改消息體
部分的代理模式中時通過刪除特定媒體類型來修改已經發起的會話的操作。
在圖9中預見的情況假定,通過圖7和8的操作添加的第三和第四媒體被再
次刪除。

在步驟701中,CPM客戶端110向CPM服務器120發送用于從在CPM
客戶端110和CPM服務器120之間發起的會話中刪除第三和第四媒體的媒
體刪除請求消息。媒體刪除請求消息包括用于第一和第二媒體的SDP參數。

在步驟703中,CPM服務器120選擇對于該媒體刪除請求的目標會話。
也就是說,CPM服務器120選擇在CPM服務器120和第三IWF?143之間發
起的第三會話以便刪除第三媒體,并且選擇在CPM服務器120和第一IWF
141之間發起的(第一媒體+第四媒體)會話以便刪除第四媒體。

在步驟705中,CPM服務器120產生用于從選擇的(第一媒體+第四媒
體)會話中刪除第四媒體的媒體刪除請求消息,然后向第一IWF?141發送產
生的媒體刪除請求消息。在步驟707中,CPM服務器120產生媒體刪除請
求消息,其請求選擇的第三媒體會話刪除第三媒體。但是,由于第三媒體會
話除了第三媒體之外不包括其它媒體,因此CPM服務器120產生會話終止
消息(BYE),然后向第三IWF?143發送會話終止消息。

在步驟709中,第一IWF?141產生對第四媒體刪除請求消息的接受響應
消息,然后將接受響應消息發送回CPM服務器120。在步驟711中,從在
CPM服務器120和第一IWF?141之間發起的(第一媒體+第四媒體)會話中
刪除第四媒體。在步驟713中,第三IWF?143產生對在步驟707中接收到的
會話終止請求的接受響應消息,然后將接受響應消息發送回CPM服務器
120。在步驟715中,終止在CPM服務器120和第三IWF?143之間發起的第
三媒體會話。

在步驟717中,CPM服務器120產生對在步驟701中接收到的媒體刪
除請求的響應消息,然后將該響應消息發送回CPM客戶端110。在步驟719
中,從在CPM客戶端110和CPM服務器120之間發起的(第一媒體+第二
媒體+第三媒體+第四媒體)會話中刪除第三和第四媒體。

圖10和11示出了根據本發明的第四實施例的當ISF工作在不允許修改
消息體部分的代理模式中時通過向會話添加新的媒體同時從會話中刪除現
有媒體來修改已經發起的會話的操作。也就是說,圖10和11的操作與改變
特定媒體類型的操作對應,并且在圖10和11中預見的情況假定,將第三和
第四媒體添加到通過圖3和4的操作發起的會話并且從該會話中刪除第二媒
體。

在步驟801中,CPM客戶端110向CPM服務器120發送用于向在CPM
客戶端110和CPM服務器120之間發起的會話添加第三和第四媒體并且從
該會話中刪除第二媒體的媒體修改請求消息。媒體修改請求消息包括用于第
一、第三和第四媒體的SDP參數。

在步驟803中,CPM服務器120選擇對于該媒體刪除請求的目標會話。
也就是說,CPM服務器120選擇在CPM服務器120和第二IWF?142之間發
起的第二會話以便刪除第二媒體。在步驟805中,CPM服務器120產生用
于向選擇的第二媒體會話添加第三和第四媒體并且從該會話中刪除第二媒
體的會話修改請求消息,并且向第二IWF?142發送會話修改請求消息。會話
修改消息包括用于第三和第四媒體的SDP參數。

在步驟807中,第二IWF?142發送回拒絕響應消息,因為第二IWF?142
不能支持第三和第四媒體。在步驟809中,CPM服務器120可以再次產生
第二媒體刪除請求消息,并且向第二IWF?142發送第二媒體刪除請求消息。
但是,由于第二媒體會話除了要被刪除的第二媒體之外不包括其它媒體,因
此CPM服務器120向第二IWF?142發送會話終止請求消息(BYE),而不是
媒體刪除請求消息。在步驟811中,第二IWF?142發送回對會話終止請求消
息的接受響應消息。在步驟813中,終止在CPM服務器120和第二IWF?142
之間發起的第二媒體會話。

在步驟815中,由于因第二IWF?142的屬性而拒絕向第二會話添加第三
和第四媒體,因此CPM服務器120產生用于向還沒有向其發送媒體添加請
求的第一媒體會話添加第三和第四媒體的媒體添加請求消息,然后在步驟
817中,向第一IWF?141發送產生的媒體添加請求消息。媒體添加請求消息
包括用于第一、第三和第四媒體的SDP參數。

在步驟819中,由于第一IWF?141支持第一和第四媒體,但是不支持第
三媒體,因此第一IWF?141接受第一和第四媒體,但是拒絕第三媒體。因而,
第一IWF?141發送回包括這樣的細節的響應消息。也就是說,響應消息包括
指示第三媒體由于第一IWF?141的屬性而被拒絕的信息。由于第一和第四媒
體被接受,因此在步驟821中,以包括第一和第四媒體的方式修改第一媒體
會話。

在步驟823中,CPM服務器120重試對由于第一或第二IWF?141、142
的屬性而被拒絕的第三媒體的添加請求。但是,由于CPM服務器120已經
請求了向已經發起的會話的媒體添加,因此CPM服務器120產生對于第三
媒體的會話發起請求消息,而不是媒體添加請求消息。隨后,在步驟825中,
CPM服務器120確定對于產生的會話發起請求消息是否需要互配。在圖10
和11中,假定需要互配。

在步驟827中,CPM服務器120向ISF?130發送對于第三媒體的會話發
起請求消息。在步驟829中,ISF?130選擇最適合于會話發起的IWF。這里
假定選擇了第三IWF?143。在步驟831中,ISF?130向第三IWF?143發送會
話發起請求消息。在步驟833中,第三IWF?143產生對會話發起請求的接受
響應消息,然后將接受響應消息發送回ISF?130。在步驟835中,ISF?130向
CPM服務器120傳送響應消息,然后在步驟837中,在CPM服務器120和
第三IWF?143之間發起第三媒體會話。

在步驟839中,CPM服務器120產生對在步驟801中接收到的會話修
改請求消息(用于添加第三和第四媒體并且刪除第二媒體的消息)的響應消
息,然后將響應消息發送回CPM客戶端110。響應消息包括指示請求的所
有CPM客戶端110都被接受的細節。在步驟841中,以包括第一、第三和
第四媒體的方式修改在CPM客戶端110和CPM服務器120之間的會話。

現在將描述在本發明的第二到第四實施例中CPM服務器如何工作。在
圖12中示出的操作與CPM服務器從CPM客戶端接收會話修改請求消息的
情況對應,以及在圖13和14中示出的操作與CPM服務器從IWF接收對會
話修改請求的響應消息的情況對應。

圖12示出了當ISF工作在根據本發明的第二到第四實施例的不允許修
改消息體部分的代理模式中時接收會話修改請求消息的CPM服務器的操
作。

在步驟901中,CPM服務器從CPM客戶端接收會話修改消息
(Re-INVITE)。會話修改請求消息包括指示要被修改的會話是在CPM服務
器和CPM客戶端之間發起的會話的信息。在步驟903中,CPM服務器從映
射到接收客戶端的會話當中選擇對于該會話修改請求的目標媒體會話。當存
在幾個對于會話修改請求的目標媒體會話時,CPM服務器立即選擇幾個媒
體會話。例如,如果會話修改請求是用于刪除幾個媒體類型的媒體或改變媒
體類型的請求,并且所有請求的媒體不包括在一個媒體會話中,則可以全部
選擇包括請求的媒體的媒體會話。

當CPM服務器選擇媒體會話時,它可以如下工作:

如果來自于CPM客戶端的會話修改請求是媒體添加請求,則CPM服務
器可以存儲包括在已經在會話發起時從IWF發送回的響應消息中的細節,
然后利用該細節。也就是說,當來自于IWF的響應消息包括如表2或3所
示的關于相應的IWF支持的媒體類型的信息時,CPM服務器可以存儲關于
相應的媒體類型的信息,然后利用該信息來檢查在媒體添加請求消息中請求
的媒體是否被相應的IWF支持,并且選擇將向其添加請求的媒體的目標媒
體會話。如果會話修改請求是對特定媒體的媒體刪除請求或用于將特定媒體
改變為其它媒體的請求,則CPM服務器可以立即選擇該媒體會話,因為它
知道哪個媒體包括在當前媒體會話中。

在步驟905中,CPM服務器產生被適配為選擇的媒體會話的會話修改
請求消息,并且向參與相應的媒體會話的IWF發送會話修改請求消息。當
幾個媒體會話被選擇為要被修改的媒體會話時,CPM服務器產生對于該幾
個媒體會話的會話修改請求消息,并且向相應的IWF發送會話修改請求消
息。

如果會話修改請求是媒體刪除請求,并且選擇的媒體會話包括除了請求
的媒體之外的其它媒體,則CPM服務器產生媒體刪除請求消息(Re-INVITE)
并且向相應的IWF發送媒體刪除請求消息。但是,如果選擇的媒體會話不
包括除了請求的媒體之外的其它媒體,則CPM服務器產生對于選擇的媒體
會話的會話終止請求消息(BYE),并且向相應的IWF發送會話終止請求消
息。

圖13和14示出了根據本發明的第二到第四實施例的當ISF工作在不允
許修改消息體部分的代理模式中時從IWF接收響應消息的CPM服務器的操
作。圖13和14假定包括在會話修改請求消息中的媒體添加請求可以被接收
客戶端拒絕或由于IWF的屬性而被拒絕,但是媒體刪除請求和媒體類型改
變請求可以僅僅由接收客戶端拒絕。

在步驟1001中,CPM服務器120從ISF?130接收對會話修改請求的響
應消息。在步驟1003中,當響應消息是對包括媒體添加請求的會話修改請
求的響應時,CPM服務器120進行到步驟1005。包括媒體添加請求的會話
修改請求是指用于僅僅添加新的媒體的請求或用于改變媒體類型的請求。在
步驟1005中,當響應消息是接受響應消息(200?OK)時,CPM服務器120
進行到步驟1007,并且修改相應的會話以使得向其添加請求的媒體。但是,
當響應消息不是接受響應消息時,CPM服務器120進行到步驟1025。

在步驟1009中,如果在請求的媒體當中媒體由于IWF的屬性而被拒絕,
則CPM服務器進行到步驟1011。否則,CPM服務器120進行到步驟1023,
并且產生對來自于CPM客戶端的會話修改請求的響應消息,并且將響應消
息發送回CPM客戶端。

在步驟1011中,如果在連接到CPM服務器120的媒體會話當中存在還
沒有向其發送媒體會話修改請求的媒體會話,則CPM服務器120進行到步
驟1013。在步驟1013中,CPM服務器選擇還沒有向其發送媒體會話修改請
求的媒體會話中的任何一個,并且產生被適配為選擇的媒體會話的對于被拒
絕的媒體的媒體添加請求消息。在步驟1015中,CPM服務器向選擇的IWF
發送產生的媒體添加請求消息。隨后,CPM服務器返回到步驟1001以便處
理對發送的媒體添加請求消息的響應消息。

在步驟1011中,如果不存在還沒有向其發送媒體會話修改請求的媒體
會話,則CPM服務器120進行到步驟1029。在步驟1029中,CPM服務器
120產生對于由于IWF的屬性被拒絕的媒體的會話發起請求消息(INVITE)。
在步驟1031中,CPM服務器確定對于產生的會話發起請求消息是否需要互
配。當需要互配時,CPM服務器進行到步驟1033,并且向ISF?130發送會
話發起請求消息。當不需要互配時,CPM服務器進行到步驟1035。

由于不需要互配意味著接收客戶端是CPM客戶端,因此CPM服務器向
接收客戶端的地址發送會話發起請求消息。當接收客戶端與CPM服務器120
位于同一個網絡區域中時,將會話發起請求消息發送給接收CPM客戶端
110。但是,當接收客戶端位于不同的網絡區域中時,將會話發起請求消息
發送給屬于相應的網絡區域的CPM服務器120。隨后,如果CPM服務器120
接收到對會話發起請求的響應消息,則CPM服務器120返回到步驟1001以
便處理響應消息。

在步驟1003中,當接收到的響應消息不是對包括媒體添加請求的會話
修改請求的響應消息時,即當接收到的響應消息是對媒體刪除請求的響應消
息時,CPM服務器進行到步驟1017。在步驟1017中,當接收到的響應消息
是接受響應消息(200?OK)時,即當會話修改請求被接受時,CPM服務器
進行到步驟1019,并且修改目標媒體會話以使得被接受的細節,即媒體刪除
被反映在目標媒體會話中。但是,當接收到的響應消息是拒絕響應消息時,
CPM服務器進行到步驟1021,并且保持現有會話。在步驟1023中,CPM
服務器產生對來自于CPM客戶端110的會話修改請求的響應消息,并且將
響應消息發送回CPM客戶端110。

在步驟中1005,當接收到的響應消息是拒絕響應消息時,CPM服務器
進行到步驟1025。在步驟1025中,由于如果拒絕響應不是由于IWF的屬性
而不需要重試會話修改請求,因此CPM服務器進行到步驟1021,并且保持
現有會話。如果拒絕響應是由于IWF的屬性,則CPM服務器進行到步驟
1026。在步驟1026中,CPM服務器確定拒絕響應是否是對媒體添加請求或
媒體類型改變請求的拒絕響應。在對媒體添加請求的拒絕響應的情況下,
CPM服務器進行到步驟1011,并且創建媒體添加請求消息或媒體發起請求
消息。

但是,當拒絕響應是對媒體類型改變請求的拒絕響應時,同時執行步驟
1011和1027。也就是說,媒體類型改變請求是用于添加新的媒體并刪除先
前的媒體的請求。但是,由于用于添加請求的新的媒體不被IWF支持,因
此CPM服務器120必須分開做出媒體添加請求和媒體刪除請求。因而,在
步驟1027中,CPM服務器產生媒體刪除請求消息,并且將它重新發送到相
應的IWF。同時,CPM服務器120進行到步驟1011和后面的步驟,并且處
理媒體添加請求。

B.允許修改消息體部分的情況

工作在允許修改消息體部分的代理模式中的IWF以和工作在B2BUA模
式中的ISF基本上相同的方式工作。但是,該過程的不同之處在于,雖然工
作在B2BUA模式中的ISF在傳送消息之前將媒體的目的地址和端口設置為
該消息的SDP體中的IWF的目的地址和端口,但是工作在B2BUA模式中
的ISF整體發送從CPM服務器接收到的SDP體,因為CPM服務器不能修
改消息體。下面將描述當ISF工作在B2BUA模式中時發起和修改會話的過
程。

ISF:B2BUA模式

當IWF工作在代理模式中時,在CPM客戶端和CPM服務器之間發起
包括由CPM客戶端請求的全部媒體的一個會話,并且可以根據IWF支持的
媒體類型在CPM服務器和IWF之間發起幾個媒體會話。因此,一個會話在
CPM服務器處分離成幾個媒體會話。

當IWF工作在B2BUA模式中時,在CPM客戶端和CPM服務器之間,
以及在CPM服務器和ISF之間發起包括由CPM客戶端請求的全部媒體的一
個會話。但是,可以根據IWF支持的媒體類型在ISF和IWF之間發起幾個
媒體會話。因此,與代理模式不同,一個會話在ISF處分離成幾個媒體會話。

B2BUA模式中的每個實體如下工作:

在接收到會話發起或修改請求消息時,CPM服務器確定是否需要互配,
然后當需要互配時向ISF發送會話發起或修改請求消息。此外,在從ISF接
收到對會話發起或修改請求消息的響應消息時,CPM服務器向CPM客戶端
傳送響應消息。

IWF以和在代理模式中相同的方式工作,并且ISF以和代理模式中的
CPM服務器基本相同的方式工作。

圖15和16示出了根據本發明的第五實施例的當ISF工作在B2BUA模
式中時發起會話的操作。

在步驟1101中,CPM客戶端110向CPM服務器120發送包括第一和
第二媒體的會話發起請求消息(INVITE)。在步驟1103中,CPM服務器120
確定對于會話發起是否需要互配。由于假定接收客戶端是非CPM客戶端,
因此需要互配。因而,在步驟1105中,CPM服務器120向ISF?130發送會
話發起請求消息。

在步驟1107中,ISF?130選擇適合于會話發起的IWF。圖15和16假定
選擇了支持第一媒體的第一IWF?141。因而,在步驟1109中,ISF?130向第
一IWF?141發送會話發起請求消息。在步驟1111中,第一IWF?141發送回
對會話發起請求的接受響應消息(200?OK)。由于第一IWF?141支持第一媒
體但是不支持第二媒體,因此接受響應消息包括指示第二媒體由于第一IWF
141的屬性而被拒絕,即第二媒體是不被第一IWF?141支持的特定類型的細
節。在步驟1113中,在ISF?130和第一IWF?141之間發起包括第一媒體的媒
體會話。

在步驟1115中,ISF?130檢查是否允許重試用于被拒絕的第二媒體的會
話發起。這里假定允許重試會話發起。因而,在步驟1117中,ISF?130產生
對于被拒絕的第二媒體的會話發起請求消息。在步驟1119中,ISF?130選擇
第二IWF?142作為向其發送會話發起請求消息的IWF,然后在步驟1121中,
向選擇的第二IWF?142發送會話發起請求消息。

在步驟1123中,第二IWF?142發送回接受響應消息(200?OK)。在步驟
1125中,然后在ISF?130和第二IWF?142之間發起包括第二媒體的媒體會話。
在步驟1127中,ISF?130產生對在步驟1105中接收的會話發起請求消息的
響應消息,并且將該響應消息發送回CPM服務器120。響應消息包括指示
第一和第二媒體都被接受的細節。在步驟1129中,在CPM服務器120和ISF
130之間發起包括第一和第二媒體的會話。在步驟1131中,CPM服務器120
產生對在步驟1131中接收的會話發起請求消息的響應消息,并且將該響應
消息發送回CPM客戶端110。響應消息包括指示第一和第二媒體都被接受
的細節。在步驟1133中,在CPM客戶端110和CPM服務器120之間發起
包括第一和第二媒體的會話。

圖21和22示出了根據本發明的第五實施例的當ISF工作在B2BUA模
式中時發起會話的另一個操作。在圖5中,ISF?130從各個IWF接收全部響
應消息,將它們組合成單個響應消息,將該單個響應消息傳送到CPM服務
器120,最后發起會話。相反,在圖21和22中,ISF?130基于從主要執行互
配的IWF(第一IWF)接收到的響應消息,首先發起與CPM服務器120的
會話。隨后,當從次要執行互配的IWF(第二IWF?142)接收到接受響應消
息時,ISF?130將第二IWF?142另外接受的媒體添加到在ISF?130和CPM服
務器120之間、以及在CPM服務器120和CPM客戶端110之間已經發起的
會話。因此,除這些特征之外,圖21和22中的其余步驟與圖5中的那些相
同。

在步驟1401中,CPM客戶端110向CPM服務器120發送包括第一和
第二媒體的會話發起請求消息(INVITE)。在步驟1403中,CPM服務器120
確定對于會話發起是否需要互配。由于假定接收客戶端是非CPM客戶端,
因此需要互配。因而,在步驟1405中,CPM服務器120向ISF?130發送會
話發起請求消息。

在步驟1407中,ISF?130基于包括接收客戶端的優選項和存在、為之做
出會話發起請求的媒體類型、接收客戶端訂制的服務、服務策略等的信息,
選擇最適合于執行會話發起的IWF。假定ISF?130在步驟1407中選擇第一
IWF?141。

在步驟1409中,ISF?130向第一IWF?141發送會話發起請求消息。在步
驟1411中,第一IWF?141產生并發送回“200?OK”作為對會話發起請求消
息的接受響應消息,因為它支持第一媒體。在步驟1413中,在ISF?130和第
一IWF?141之間發起對于被接受媒體的會話。在步驟1411中,第一IWF?141
在響應消息中包括指示第一媒體被接收方用戶接受并且第二媒體由于是不
被第一IWF?141支持的媒體而被自動拒絕的細節。

在步驟1415中,ISF?130將響應消息發送到CPM服務器120。在步驟
1417中,在CPM服務器120和第一IWF?141之間發起第一媒體會話。ISF?130
向CPM服務器120發送響應消息的時間點可以根據ISF?130的操作模式而
變化。換句話說,ISF?130可以等待特定時間段以接收對在步驟1429中發送
的新的會話發起請求的響應消息,或者可以一旦從第一IWF?141接收到第一
響應消息就向CPM服務器120發送響應消息。圖21和22假定后者。在前
者情況下,當在固定時間段期間接收到對新的會話發起請求的響應消息時,
ISF?130集成這些響應消息,然后向CPM服務器120發送最終的響應消息,
如圖15和16的操作中所示。如果在該固定時間段之外接收到對新的會話發
起請求的響應消息,則ISF?130首先向CPM服務器120發送首先接收到的
響應消息以發起對于被接受的媒體的會話,然后根據隨后的對新的會話發起
請求的響應消息的內容修改或保持發起的會話。

在步驟1419中,CPM服務器120將響應消息發送到CPM客戶端110。
在步驟1421中,在CPM客戶端110和CPM服務器120之間發起第一媒體
會話。

在步驟1423中,ISF?130檢查是否允許重試對于被第一IWF?141自動拒
絕的第二媒體的會話發起請求。如果允許,則ISF?130在步驟1425中產生對
于第二媒體的新的會話發起請求,并且在步驟1427中選擇最適合于處理新
的會話發起請求的IWF。這里假定ISF?130選擇支持第二媒體的第二IWF
142。在步驟1429中,ISF?130向第二IWF?142發送新的會話發起請求。

在步驟1423中,第二IWF?142向ISF?130發送“200?OK”作為接受響
應消息。在步驟1433中,在ISF?130和第二IWF?142之間發起第二媒體會話。

在步驟1435中,ISF?130向CPM服務器120發送會話修改請求。在步
驟1435中的會話修改請求是用于向在CPM服務器120和IWF?130之間發起
的第一媒體會話添加第二媒體的請求。

在步驟1437中,CPM服務器120向CPM客戶端110發送會話修改請
求。在步驟1437中的會話修改請求是用于向在CPM客戶端110和CPM服
務器120之間發起的第一媒體會話添加第二媒體的請求。

在步驟1439中,CPM客戶端110向CPM服務器120發送“200?OK”
作為對會話修改請求的響應消息。在步驟1441中,以包括第一和第二媒體
的方式修改CPM客戶端110和CPM服務器120之間的會話。此外,在步驟
1443中,CPM服務器120向ISF?130發送″200?OK″。然后,在步驟1445中,
以包括第一和第二媒體的方式修改CPM服務器120和ISF?130之間的會話。

圖15和16的根據本發明的第五實施例的ISF處理會話發起請求的操作
與圖6中描述的CPM服務器的操作相同。但是,在B2BUA模式中,圖6
的操作由ISF執行,因而圖6中的步驟513和509必須被如下修正。也就是
說,步驟509必須被修訂為“產生對會話發起請求的響應消息,并將它發送
回CPM服務器”,以及步驟513必須被修訂為“選擇最適合于處理在步驟
511中產生的會話發起請求消息的IWF,并將會話發起請求消息發送到選擇
的IWF”。

圖17和18示出了根據本發明的第六實施例的當ISF工作在B2BUA模
式中時通過改變特定媒體類型來修改已經發起的會話的操作。也就是說,圖
17和18預見的情況假定,將新的媒體,即第三和第四媒體添加到已經在圖
15和16中發起的包括第一和第二媒體的會話,同時從該會話中刪除第二媒
體。

在步驟1201中,CPM客戶端110向CPM服務器120發送用于向已經
發起的會話添加第三和第四媒體并且從該會話中刪除第二媒體的會話修改
請求消息。

在步驟1201中的會話修改請求消息包括用于第一、第三和第四會話的
SDP參數。在步驟1203中,CPM服務器120將接收的會話修改請求消息傳
送到ISF?130。

在步驟1205中,ISF?130選擇第二媒體會話作為對于該會話修改請求的
目標會話。在步驟1207中,ISF?130產生被適配為第二媒體會話的會話修改
請求消息,并且向第二IWF?142發送該會話修改請求消息。在步驟1207中
的會話修改請求消息包括用于第三和第四會話的SDP參數。在步驟1209中,
第二IWF?142發送回拒絕響應消息,因為第二IWF?142不支持第三和第四媒
體。

在步驟1211中,ISF?130將用于從第二媒體會話中刪除第二媒體的請求
重新發送到第二IWF?142。由于第二媒體會話除了第二媒體之外當前不包括
其它媒體,因此ISF?130向第二IWF?142發送對于第二媒體會話的會話終止
請求消息(BYE)。

在步驟1213中,第二IWF?142發送回對會話終止請求消息的接受響應
消息。在步驟1215中,終止ISF?130和第二IWF?142之間的第二會話。

在步驟1217中,ISF?130產生用于向還沒有為其做出媒體添加請求的第
一媒體會話添加被拒絕的第三和第四媒體的媒體添加請求消息,然后在步驟
1219中,向第一IWF?141發送產生的媒體添加請求消息。媒體添加請求消
息包括用于第一、第三和第四媒體的SDP參數。

由于第一IWF?141支持第一和第四媒體,但是第一IWF?141不支持第三
媒體,因此第一IWF?141接受第一和第四媒體而拒絕第三媒體。因而,在步
驟1221中,第一IWF?141發送回包括這樣的細節的響應消息。也就是說,
響應消息包括指示第三媒體由于第一IWF?141的屬性而被拒絕的信息。在步
驟1223中,由于第一和第四媒體被接受,因此以包括第一和第四媒體的方
式修改第一媒體會話。

在步驟1225中,ISF?130再次產生對于被拒絕的第三媒體的會話發起請
求消息。為了產生的會話發起請求消息的互配,ISF?130在步驟1227中選擇
第三IWF?143,并且將在步驟1225中產生的會話發起請求消息傳送到第三
IWF?143。在步驟1231中,第三IWF?143產生并發送回對會話發起請求的接
受響應消息。在步驟1233中,在ISF?130和第三IWF?143之間發起第三媒體
會話。

在步驟1235中,ISF?130產生對在步驟1203中接收到的會話修改請求
的接受響應消息,然后將接受響應消息發送回CPM服務器120。步驟1235
中的響應消息包括指示請求的所有CPM服務器120都被接受的細節。隨后,
在步驟1237中,以包括第一、第三和第四媒體的方式修改CPM服務器120
和ISF?130之間的會話。

在步驟1239中,CPM服務器120產生對在步驟1201中接收到的會話
修改請求的接受響應消息,然后將接受響應消息發送回CPM客戶端110。
步驟1239中的響應消息包括指示請求的所有CPM客戶端110都被接受的細
節。在步驟1241中,以包括第一、第三和第四媒體的方式修改在CPM客戶
端110和CPM服務器120之間的會話。

在圖17和18的操作中,可以根據ISF?130的實施方式修正步驟1207到
1217。換句話說,ISF?130可以向支持相應的媒體的IWF發送對于第二媒體
的媒體刪除請求(Re-INVITE)或對于第二媒體會話的會話終止請求(BYE),
并且同時發送對于第三和第四媒體的會話發起請求(INVITE)。這是可以的,
因為ISF?130已經知道每個IWF支持哪些媒體類型。

根據本發明的第六實施例的ISF處理會話修改請求的操作與圖13和14
中描述的CPM服務器的操作相同。但是,步驟1031被如下修正。在圖13
和14中的代理模式的情況下,CPM服務器根據是否需要互配而進行到步驟
1033或1035,并且向ISF或接收客戶端的地址發送會話發起請求消息。但
是,由于在B2BUA模式中是否需要互配是由CPM服務器確定的,因此
B2BUA模式中的步驟1031必須被修訂為“選擇最適合于執行在步驟1029
中產生的會話發起請求消息的IWF,并且將會話發起請求消息發送到選擇的
IWF”。此外,省略不必要的步驟1033和1035,并且隨后ISF返回到步驟501
以便處理對會話發起請求消息的響應消息。

盡管已經參考本發明的特定示范性實施例對本發明進行了圖示和描述,
但是本領域技術人員應當理解,在不脫離由所附權利要求書所定義的本發明
的精神和范圍的情況下,可以對本發明做出形式和細節上的各種修改。

關 鍵 詞:
融合 互聯網 協議 消息 服務 控制 用于 會話 方法 裝置 及其 系統
  專利查詢網所有資源均是用戶自行上傳分享,僅供網友學習交流,未經上傳用戶書面授權,請勿作他用。
關于本文
本文標題:在融合互聯網協議消息服務中控制用于互配的會話的方法和裝置及其系統.pdf
鏈接地址:http://www.rgyfuv.icu/p-6420356.html
關于我們 - 網站聲明 - 網站地圖 - 資源地圖 - 友情鏈接 - 網站客服客服 - 聯系我們

[email protected] 2017-2018 zhuanlichaxun.net網站版權所有
經營許可證編號:粵ICP備17046363號-1 
 


收起
展開
山东11选5中奖结果走势图