專利名稱:用于多媒體會話的多用戶實時代碼轉(zhuǎn)換系統(tǒng)與方法
技術(shù)領(lǐng)域:
一般地,本發(fā)明涉及用來建立多用戶通信會話的系統(tǒng)與方法。更具體地 而不是排他地,本發(fā)明涉及用于蜂窩式多i某體會話上的推壓講話(push to talk) 的多方實時代碼轉(zhuǎn)換系統(tǒng)與方法。
背景技術(shù):
蜂窩式推壓講話(PoC)服務(wù)允許移動用戶建立組會話,其中參加者可以 在一對一或者一對多基礎(chǔ)上進行語音與數(shù)據(jù)通信[l]。語音通信類似于步話機 服務(wù),其中終端具有專用的"講話,,按鈕。在給定時間,只有一個人可以講 話,并且每次講話猝發(fā)都相對較短,例如,其持續(xù)幾秒鐘。用戶也可以交換 即時消息。不久講話猝發(fā)將演進為語音和視頻流的猝發(fā),并且即時消息將包 含豐富的4某體內(nèi)容,例如音頻、視頻、文本、動畫等等。
蜂窩式推壓講話(PoC)服務(wù)規(guī)格由開放移動聯(lián)盟(OMA)定義。其基于 第三代伙伴項目(3GPP或者3GPP2 )互連網(wǎng)協(xié)議多4某體子系統(tǒng)(IMS )體系 結(jié)構(gòu)中的會話發(fā)起協(xié)議(SIP )。更具體地,PoC服務(wù)建立在SIP/IP核心之上, 其可以滿足3GPPIP多媒體子系統(tǒng)(IMS) [4, 5]或者3GPP2IMS[6, 7]的規(guī) 格。
對于通用情況的整體PoC體系結(jié)構(gòu)包括多個PoC客戶端,每個PoC客戶 端連接到其自身的參加PoC功能(在其自己的網(wǎng)絡(luò)上),參見由中心控制PoC 功能控制的公共會話。所有PoC功能都連接到中心控制PoC功能。
請注意,控制PoC功能負責(zé)管理在給定時間誰具有講話許可權(quán)(即誰有 發(fā)送音頻視頻媒體或者多i某體分組的許可權(quán)),并且負責(zé)將^ 某體分組從一個來
源拷貝到多個目的地。參加PoC功能無法進行這些操作。
由于終端與網(wǎng)絡(luò)的多樣性,所以產(chǎn)生了互操作問題。例如,3GPP要求使 用AMR (自適應(yīng)多速率)窄帶語音編解碼器作為PoC服務(wù)中的默認語音編 解碼器。如果其上實現(xiàn)PoC客戶端的用戶裝備對于語音使用16 kHz采樣頻率, 則3GPP還要求支持AMR寬帶語音編解碼器。在另 一方面,3GPP2要求EVRC (改進可變速率編碼)語音編解碼器作為默認語音編解碼器[3]。因此,由于 不兼容,分別支持AMR與EVRC音頻編解碼器的3GPP與3GPP2終端將不 能夠一起建立PoC會話。對于包含視頻和媒體的即時消息來說,同樣會產(chǎn)生 相同的不兼容性。為了解決這一問題,需要代碼轉(zhuǎn)換。代碼轉(zhuǎn)換允許在網(wǎng)絡(luò) 元件中從一種格式轉(zhuǎn)換為另一種格式,以滿足每個參加者的終端能力。
因為PoC服務(wù)建立在3GPP/3GPP2 IMS SIP/IP核心之上,所以媒體由 MRFC/MRFP (媒體資源功能控制器/媒體資源功能處理器)控制和處理[4, 8],對于通信目的其使用H.248/MGCP0某體網(wǎng)關(guān)控制協(xié)議)協(xié)議[9-11]。但是 這些規(guī)格很復(fù)雜,并且開發(fā)符合這些協(xié)議的解決方案要求付出巨大努力。另 外,由于H.248/MGCP復(fù)雜昂貴、并且其是不是基于SIP的唯一 IMS關(guān)鍵系 統(tǒng)組件,人們正在批評它并且向其提出挑戰(zhàn)。由于這些原因,需要以更通用 的框架來處理Poc應(yīng)用中的代碼轉(zhuǎn)換問題,其不限于MRFC/MRFP以及 H,248/MGCP。另外,雖然MRFC/MRFP功能與接口定義完備,但是沒有定 義其在PoC環(huán)境下的使用。
在PoC標(biāo)準(zhǔn)中,人們認識到需要代碼轉(zhuǎn)換,但是沒有提供詳細的解決方 案。在[l]中據(jù)說可以由控制PoC功能(CPF)和/或參加PoC功能(PPF)兩 者進行代碼轉(zhuǎn)換,但是沒有進一步的細節(jié)。因此重要的是開發(fā)一種代碼轉(zhuǎn)換 體系結(jié)構(gòu),其支持各種配置與使用情況。在某些情況下,還非常希望以透明 方式添加代碼轉(zhuǎn)換,從而其可以與已經(jīng)部署的PoC裝備相適合并且一起工作。
總而言之,需要一種支持PoC環(huán)境下代碼轉(zhuǎn)換的通用解決方案。該解決 方案應(yīng)該與現(xiàn)有的PoC體系結(jié)構(gòu)和協(xié)議兼容,從而被接受和集成到標(biāo)準(zhǔn)方案 中,例如3GPP、 3GPP2、以及OMA。另外,該解決方案需要是靈活的,以 能夠適合于不同的裝備部署情況和限制。
發(fā)明內(nèi)容
因此,本發(fā)明的非限定性目的在于提供一種用于蜂窩式推壓講話(PoC)
多媒體會話的多方實時代碼轉(zhuǎn)換系統(tǒng)和方法。
更具體地,根據(jù)本發(fā)明,提供了一種用來建立在具有非兼容媒體特性的
終端之間的、具有會話描述的多用戶通信會話的方法,該方法包括邀請具 有非兼容媒體特性的終端的用戶參加所述通信會話;設(shè)置代碼轉(zhuǎn)換會話,使 之能夠根據(jù)關(guān)于接受了邀請的用戶的終端的信息,進行所述終端的非兼容媒 體特性之間的代碼轉(zhuǎn)換,所述信息包含該用戶的終端的媒體特性;根據(jù)所述 代碼轉(zhuǎn)換會話,建立所述會話描述;以及在所述通信會話期間,利用參加所 述通信會話的其他用戶的終端的媒體特性,根據(jù)所述代碼轉(zhuǎn)換會話,對來自 一個用戶的終端的々某體流進行代碼轉(zhuǎn)換,并且才艮據(jù)所述會話描述,將代碼轉(zhuǎn) 換的媒體流發(fā)送給所述其他用戶。
本發(fā)明還涉及一種用來建立在具有非兼容媒體特性的終端之間的、具有 會話描述的多用戶通信會話的系統(tǒng),該系統(tǒng)包括用來邀請具有非兼容媒體 特性的終端的用戶參加所述通信會話的部件;用來設(shè)置代碼轉(zhuǎn)換會話,使之 能夠根據(jù)關(guān)于接受了邀請的用戶的終端的信息,進行所述終端的非兼容媒體 特性之間的代碼轉(zhuǎn)換的部件,所述信息包含該用戶的終端的媒體特性;用來 根據(jù)所述代碼轉(zhuǎn)換會話,建立所述會話描述的部件;以及在所述通信會話期 間,用來利用參加所述通信會話的其他用戶的終端的媒體特性,根據(jù)所述代 碼轉(zhuǎn)換會話,對來自一個用戶的終端的媒體流進行代碼轉(zhuǎn)換,并且根據(jù)所述 會話描述,將代碼轉(zhuǎn)換的々某體流發(fā)送給所述其他用戶的部件。
本發(fā)明還涉及一種用來建立在具有非兼容々某體特性的終端之間的、具有 會話描述的多用戶通信會話的系統(tǒng),該系統(tǒng)包括網(wǎng)絡(luò)元件,用來邀請具有 非兼容i某體特性的終端的用戶參加所述通信會話;代碼轉(zhuǎn)換服務(wù)器,用來設(shè) 置代碼轉(zhuǎn)換會話,使之能夠根據(jù)關(guān)于接受了邀請的用戶的終端的信息,進行
所述終端的非兼容^某體特性之間的代碼轉(zhuǎn)換,所述信息包含該用戶的終端的 媒體特性;其中所述代碼轉(zhuǎn)換服務(wù)器根據(jù)所述代碼轉(zhuǎn)換會話,建立所述會 話描述;以及在所述通信會話期間,所述代碼轉(zhuǎn)換服務(wù)器利用參加所述通信 會話的其他用戶的終端的々某體特性,根據(jù)所述代碼轉(zhuǎn)換會話,對來自一個用 戶的終端的媒體流進行代碼轉(zhuǎn)換,并且根據(jù)所述會話描述,將代碼轉(zhuǎn)換的媒 體流發(fā)送給所述其他用戶。
述,將清楚本發(fā)明的以上以及其他目的、優(yōu)點以及特點。
在附圖中
圖1為顯示PoC體系結(jié)構(gòu)中對于語音傳送的"一對多"組會話的示意圖; 圖2顯示通用PoC體系結(jié)構(gòu);
圖3顯示根據(jù)本發(fā)明的第一非限定性示范實施例的具有代碼轉(zhuǎn)換的PoC
應(yīng)用的高級體系結(jié)構(gòu);
圖4顯示當(dāng)設(shè)置會話時在SIP INVITE請求內(nèi)包含的SDP會話描述;
圖5A與圖5B為顯示在PoC應(yīng)用中為保證適當(dāng)通信會話的CPF的角色的
示意圖,其中在圖5A中,CPF不支持代碼轉(zhuǎn)換,在圖5B中,CPF支持代碼轉(zhuǎn)
換;
圖6顯示在圖3的體系結(jié)構(gòu)中集中在CFP上的、并且其中所有i某體分組 都在TS (代碼轉(zhuǎn)換服務(wù)器)之前到達CPF的代碼轉(zhuǎn)換方案的媒體流動;
圖7顯示集中在CFP上的、并且其中所有媒體分組都在去向CPF之前到 達TS的代碼轉(zhuǎn)換方案的媒體流動的非限定性例子;
圖8顯示圖7的集中在CFP上的代碼轉(zhuǎn)換方案的會話控制流;
圖9顯示在圖7的集中在CFP上的代碼轉(zhuǎn)換方案中對于當(dāng)新參加者具有 講話許可權(quán)時的情況的控制流;
圖10顯示對于圖7的集中在CFP上的代碼轉(zhuǎn)換方案的信令流;
圖11顯示對于圖7的集中在CFP上的代碼轉(zhuǎn)換方案的在TS (代碼轉(zhuǎn)換 服務(wù)器)、CPF、以及用戶終端之間的IP地址與端口路由設(shè)置;
圖12顯示根據(jù)本發(fā)明的第二非限定性示范實施例的在被邀請用戶的PPF 上執(zhí)行的代碼轉(zhuǎn)換方案的體系結(jié)構(gòu);
圖13顯示根據(jù)本發(fā)明的第三非限定性示范實施例的集中在CFP上的透明 代碼轉(zhuǎn)換方案的體系結(jié)構(gòu);
圖14顯示圖13的集中在CFP上的透明代碼轉(zhuǎn)換方案的信令流;以及
圖15顯示圖13的集中在CFP上的透明代碼轉(zhuǎn)換方案的TS、 CPF、以及 用戶終端之間的IP地址與端口路由設(shè)置。
具體實施例方式
在以下描述中,將參照附圖,這些附圖形成了本說明書的一部分,并且 可以利用其他實施例,并且在不脫離本發(fā)明的范圍的前提下,可以進行結(jié)構(gòu) 與"^喿作的變化。
在以下描述中,將在^^窩式推壓講話(PoC)的情景下描述本發(fā)明。但是, 本發(fā)明不限于PoC應(yīng)用,并且可以用于其中在任意給定時間只有一個參加者
具有講話許可權(quán)的其他多方多媒體體系結(jié)構(gòu);該許可權(quán)由中心網(wǎng)絡(luò)元件控制。 該中心網(wǎng)絡(luò)元件可以是會話的任何中心元件,包括控制PoC功能以及多點控 制單元(MCU)。在更一般的情景下,該講話許可權(quán)可以為從一或多個用戶 導(dǎo)出、并且被分發(fā)給所有用戶的任何音頻視頻媒體流(例如從幾個用戶的視 頻流產(chǎn)生的視頻拼圖,或者幾個音頻流的混合)。還請注意,雖然參照了講話 猝發(fā)以及講話許可權(quán),但是講話一般地指向其他參加者發(fā)送媒體流的許可權(quán), 而不管這些媒體流為音頻、視頻、文本、圖形、還是其他類型。因此,將使 用術(shù)語"講話猝發(fā)",但是術(shù)語"媒體摔發(fā)"也許更適當(dāng)。該用法不限制本發(fā) 明的范圍,本發(fā)明適用于々某體的所有類型與組合。最后,在本發(fā)明的范圍內(nèi), 用戶或者參見通信會話的一方不限于利用終端或者任何其他設(shè)備參加多媒體 會話的人,而且還包括參見會議的任何自主設(shè)備,例如監(jiān)控或者記錄設(shè)備。
一般地,本發(fā)明的說明性實施例提供了一種系統(tǒng)和方法,用來使支持不 同媒體特性(類型、格式、編解碼器、或者屬性)的終端之間能夠互操作, 這些終端如果沒有這種系統(tǒng)和方法將無法建立其中在給定時間上只有一個用 戶具有發(fā)送媒體流(例如音頻和視頻)的許可權(quán)的多用戶多媒體會話。雖然 主要關(guān)心的是互操作性,但是為了方便,所提出的系統(tǒng)還進行代碼轉(zhuǎn)換。例 如,用戶終端可能支持音頻,但是如果用戶正在會議(其中不允許使用音頻) 之中則其可能希望將媒體轉(zhuǎn)換為文本。此類用法被認為是在本發(fā)明的范圍之 內(nèi),并且被包含在本發(fā)明的的術(shù)語"非兼容性"的用法中。該系統(tǒng)與方法通 過定制對于每個用戶的會話提議、并且按照需要修改用戶之間的媒體流以符 合每個參加者終端的能力甚至偏好,使能互操作性。該系統(tǒng)與方法處理多方 多媒體會話,并且可以用于PoC多媒體會話的情景。本說明書描述了幾種替 換實施例。選擇特定實施例依賴于與部署特定服務(wù)關(guān)聯(lián)的限制。在某些情況 下,性能可能最重要,而在其他情況下,透明代碼轉(zhuǎn)換可能最重要。
本發(fā)明讓人感興趣的一種可能應(yīng)用是在PoC服務(wù)中,如圖1所示。該服 務(wù)允許移動用戶建立組會話,其中參加者可以在一對一或者一對多基礎(chǔ)[l]上
進行語音和數(shù)據(jù)通信。圖1顯示PoC系統(tǒng)100,其中具有講話許可權(quán)的移動
終端102通過發(fā)送天線102、無線網(wǎng)絡(luò)106、以及"l妄收天線108與110向終端 112、 114、 116、以及118發(fā)送媒體流。無線網(wǎng)絡(luò)106中的中心元件(未顯示) 負責(zé)復(fù)制與傳輸媒體流到目的地終端112、 114、 116、以及118。
在圖2中顯示了通用PoC體系結(jié)構(gòu)200的例子。終端202與204連接到 其本地參加PoC功能(PPF ) 206, PPF 206位于其自身本地網(wǎng)絡(luò)208內(nèi),連 接到位于中心網(wǎng)絡(luò)212內(nèi)的控制PoC功能(CPF) 210。另外,終端214連 接到其本地網(wǎng)絡(luò)218內(nèi)的其本地PPF 216。本地PPF 216也連接到CPF 210。 因此,終端202與204通過中心網(wǎng)絡(luò)212互連到終端214。終端202、 204與 214參加CPF 210控制的公共通信會話。請注意,體系結(jié)構(gòu)200還可以包含 包括多個PPF (例如206與216)的、連接到多個終端(例如202、 204、以 及214)的多個本地網(wǎng)絡(luò)208與218。
l.PoC應(yīng)用中的代碼轉(zhuǎn)換
1.1在PoC應(yīng)用中使能代碼轉(zhuǎn)換要考慮的元素
在PoC版本1.0標(biāo)準(zhǔn)[1][14][15]中,人們認識到了對代碼轉(zhuǎn)換的需求,但 是沒有給出詳細的解決方案。在[l]中據(jù)說可以由控制PoC功能(CPF)和/ 或參加PoC功能(PPF)兩者進行代碼轉(zhuǎn)換。因此需要一種代碼轉(zhuǎn)換體系結(jié) 構(gòu),其支持各種配置與使用情況??傮w解決方案應(yīng)該涉及幾個元素,例如
1. 系統(tǒng)級協(xié)議流,不同實體(例如客戶端或者用戶、代碼轉(zhuǎn)換服務(wù)器 (TS)、 PoC服務(wù)器)之間的交互,以及修改不同實體之間交換的消息。
2. 代碼轉(zhuǎn)換服務(wù)器的處理體系結(jié)構(gòu)(在TS中發(fā)生的內(nèi)部處理)。
3. 代碼轉(zhuǎn)換服務(wù)器與PoC功能之間的代碼轉(zhuǎn)換接口 (TI)。 在圖3中顯示了這些元素。更具體地,圖3顯示了 PoC應(yīng)用的高級體系
結(jié)構(gòu)300,其基本與圖2的體系結(jié)構(gòu)類似,但是具有代碼轉(zhuǎn)換能力。N個本 地網(wǎng)絡(luò)302,到3022通過中心網(wǎng)絡(luò)304相互互連。每個本地網(wǎng)絡(luò)302n ( 1《n 《N)包括連接到PPF 308 n的用戶終端306n。中心網(wǎng)絡(luò)304包括CPF 310, 每個PPF 308n都連接到CPF 310。不同實體之間的連接可以屬于不同類型, 例如無線、有線、使用電纜等等。另外,代碼轉(zhuǎn)換服務(wù)器312n與314分別連 接到每個本地網(wǎng)絡(luò)302n與中心網(wǎng)絡(luò)304。更具體地,代碼轉(zhuǎn)換服務(wù)器312n通 過代碼轉(zhuǎn)換接口 316 連接到PPF 308n。并且TS 314通過代碼轉(zhuǎn)換接口 318
連接到CPF310。此類配置300允許N個用戶306i到306n參加中心網(wǎng)絡(luò)元件 CPF 310控制的、并且其中在某時間上一個用戶可以發(fā)送i某體流的公共通信 會話。
另外,圖3還顯示了用于設(shè)置會話的不同實體之間的會話流。 一旦會話 有效,則々某體流動可以例如直接穿行通過TS312n,或者在達到TS312n之前, 通過CPF 310和/或PPF 308 n。請注意,PoC服務(wù)器可以包括控制PoC功能 (CPF)、參力卩PoC功能(PPF)、或者兩者,即,CPF與PPF可以構(gòu)成單個 服務(wù)器,盡管其在邏輯上是分離的功能。
1.2會話描述協(xié)議
如圖4所示的會話描述協(xié)議(SDP ) 400為基于SIP (會話發(fā)起協(xié)議)多 媒體會話的關(guān)鍵元素,并且在[13]中定義。SDP400包括定義會話參數(shù)的多個 字段。每行對應(yīng)一個字段。SDP 400包含在SIP INVITE消息[14]內(nèi),當(dāng)發(fā)起 與其他用戶的組會話時由用戶發(fā)送該消息。
以下SDP參數(shù)讓人特別感興趣
-其中要接收媒體流的IP地址用行422上的字段"c=,,描述,其中例如 顯示了 IPV6i也址1000:900:800:700:600:efdf:2edf:3ece。
一媒體特性列表用行424與432上的字段"m="描述,例如顯示了該會話 中的兩個々某體
-用相關(guān)RTCP (實時控制協(xié)議)在端口 3456上接收的RTP (實時 協(xié)議)上的音頻在行424中顯示。對于音頻々某體,提供兩個編解碼器,并且 標(biāo)記為97與98。
陽利用UDP (用戶數(shù)據(jù)報協(xié)議)在端口 2000上接收的講話猝發(fā)控制 協(xié)議(TBCP)在行432中顯示。
-這兩個媒體的細節(jié)在行426、 428、 430與434上的字段"a=,,中描述
-對于音頻4某體,兩個標(biāo)簽97與98對應(yīng)于所^是議的兩個不同的編 解碼器AMR編解碼器或者8000Hz上的EVRC編解碼器,如行426與"8 中所示。
-在行430中提供端口 5560上的RTCP。
隱對于TBCP,在行434中提供幾種選項。 2.對于集中在控制PoC功能上的代碼轉(zhuǎn)換方案的PoC信令流 PoC規(guī)格描述了可能包含幾種邀請方法的幾種會話,其在開放移動聯(lián)盟(OMA)制定的PoC規(guī)格中描述,此處為了簡潔不進行描述。本領(lǐng)域技術(shù)人 員能夠以直接的方式將本發(fā)明用于PoC標(biāo)準(zhǔn)支持的所有情況。
在本發(fā)明的第一非限定行示范實施例中,考慮代碼轉(zhuǎn)換方案集中在控制 PoC功能上的情況
2.1在會話流中控制PoC功能的角色
在圖3所示的本發(fā)明的第一非限定行示范實施例中,除講話許可權(quán)之外, CPF 310還管理整個代碼轉(zhuǎn)換處理。不管所建立的PoC組會話的類型如何, CPF 310具有兩項主要責(zé)任
1. 保證用戶之間的適當(dāng)?shù)臅捥嶙h以及設(shè)置
因為PoC用戶可能具有具有不兼容的格式/編解碼器,所以CPF310可能 必須改變對各個用戶的SDP 400 (參見圖4 ),以包含其在組會話期間能夠使
器。例如,僅支持AMR的用戶將無法與僅支持EVRC的用戶建立直接會話。 支持AMR-EVRC的代碼轉(zhuǎn)換的CPF將在會話提議中包含AMR與EVRC兩 者。在圖5的系統(tǒng)500中顯示,其大概顯示了保證適當(dāng)會話提議的CPF角色。 在圖5的例子A)中,通過CPF 502 (其不更改邀請的會話描述),僅支持 AMR音頻編解碼器的終端504用會話描述(未顯示)邀請僅支持EVRC音頻 編解碼器的終端506來通信會話。然后終端506生成錯誤"4xx Request Failure",因為其無法支持所提議的AMR音頻編解碼器。在例子B)中,通 過CPF 512 (現(xiàn)在其更 文邀請的會話描述以符合終端510的能力),僅支持 AMR音頻編解碼器的終端508用會話描述(未顯示)邀請僅支持EVRC音頻 編解碼器的終端510來通信會話。雖然終端508發(fā)出的邀請的會話描述僅包 含AMR音頻編解碼器,由于CPF 512擴展了會話描述從而也包含終端510 的EVRC音頻編解碼器,所以終端510將發(fā)出200 OK響應(yīng)(其中以EVRC 編解碼器作為選定編解碼器),從而接受邀請。CPF 512將修改對于終端508 的邀請接受,以包含AMR編解碼器而非EVRC編解碼器,從而可以在終端 508與終端510之間進行會話,并且可以在其間交換數(shù)據(jù)。
2. 管理用戶之間的+某體流的流動
當(dāng)需要代碼轉(zhuǎn)換時,媒體流將必須流經(jīng)代碼轉(zhuǎn)換服務(wù)器(TS)(在圖5 中未顯示),其中媒體流將被適配/代碼轉(zhuǎn)換,然后被發(fā)送到其目的地。這要 求媒體流的流動由CPF 512管理。關(guān)于媒體流動,CPF 512必須管理兩種業(yè)
務(wù)講話猝發(fā)控制(TBC)以及通常媒體。第一種涉及講話請求,例如請求 講話許可權(quán),以及用戶與CPF 512之間的響應(yīng)。第二種涉及通?!┠丑w流,其 包含有用信息以及要傳送的實際數(shù)據(jù)(例如RTP與RTCP上的AMR)。每種 業(yè)務(wù)都被分配給某些特定端口號。因此,CPF 512與TS分別至少包含用于 TBC業(yè)務(wù)的端口 ,例如TBCP (講話猝發(fā)控制協(xié)議)端口 。 2.2控制PoC功能在媒體流動中的角色
對于媒體流動,可能有兩個選項。因此,在圖6的體系結(jié)構(gòu)600以及圖 7的體系結(jié)構(gòu)700中考慮并且顯示了兩種々某體流動方案。作為非限定性例子, 圖6與圖7都顯示了使用AMR/EVRC代碼轉(zhuǎn)換的體系結(jié)構(gòu)。
在圖6的體系結(jié)構(gòu)600中顯示第一種Jf某體流動方案,此時代碼轉(zhuǎn)換集中 在CPF 602上,并且其中所有的媒體分組在代碼轉(zhuǎn)換服務(wù)器(TS )之前到達 CPF 602。來自利用AMR編解碼器的終端606的用戶希望與來自利用EVRC 編解碼器的終端608的用戶通信以及交換+某體流。終端606在i某體流動610 中向CPF 602發(fā)送實時協(xié)議(RTP)上的AMR分組。在媒體流動612中, CPF 602發(fā)送這些RTP上的AMR分組給TS 604,以進行適配與代碼轉(zhuǎn)換。 在i某體流動614中,TS 604將適配的RTP上的EVRC分組返回給CFP 602, 然后,在i某體流動616中,CFP 602將其轉(zhuǎn)發(fā)給終端608。在另 一替代方案中, TS 604可以直接將適配的EVRC分組發(fā)送給終端608,而不經(jīng)過CFP 602。
在CFP 602將通常媒體流轉(zhuǎn)發(fā)給TS 604時,其自己處理到達其TBCP端 口 、來自終端606的TBC分組,并且在消息流618中,將結(jié)果返回給終端606。 實際上,包含TB請求與響應(yīng)的媒體流動618僅在終端608與CFP 602之間 傳送,而在通信路徑中不涉及TS 604。
在圖7的體系結(jié)構(gòu)700中顯示第二種々某體流動方案,此時代碼轉(zhuǎn)換集中 在CPF 702上,并且其中所有的媒體分組在CPF 702之前(或者替代CPF 702 ) 到達TS 704。在媒體流動708中,終端706發(fā)送RTP上的AMR分組給TS 704。 TS 704將AMR分組代碼轉(zhuǎn)換為EVRC分組,并且在i某體流動710中,將如 此適配的RTP上的EVRC分組發(fā)送給終端712。包含TB請求與響應(yīng)的媒體 流動714僅通過TS 704在終端706與CFP 702之間傳送。更具體地,TS 704 將i某體流動714的進入的分組轉(zhuǎn)發(fā)給^ 某體流動716的外出的去向CFP 702的 分組。并且TS 704將媒體流動716的來自CFP 702的進入的分組轉(zhuǎn)發(fā)給4某體 流動714的外出的去向終端706的分組。以同樣的方式,終端712與CFP702
可以^又通過TS 704相互交換TB請求與響應(yīng)。
因此,TS 704將到達其TBCP端口的TBC分組轉(zhuǎn)發(fā)給CFP 702,同時其 代碼轉(zhuǎn)換通常媒體流,并且將其發(fā)送給其目的地,例如到終端712。 CFP702 管理到達其TBCP端口的TBC消息,并且將響應(yīng)返回給TS 704, TS 704將 其轉(zhuǎn)發(fā)給其目的地,或者可替換地,CFP 702直接將響應(yīng)返回到其目的地。
圖7的體系結(jié)構(gòu)700被認為是優(yōu)選媒體流動方案,這是因為其要求TS704 與CPF 702之間的分組的流動4交少。
2.3控制PoC功能管理的會話控制
除上述i某體流動之外,還必須管理/提供會話控制流。會話控制流在圖8 中顯示,并且由CPF 802控制,其還管理會話本身。會話可能會影響媒體流 動。實際上,在設(shè)置通信會話之后,當(dāng)會話參數(shù)改變時,例如由于用戶加入 或者離開,或者當(dāng)不同的用戶具有講話許可權(quán)時,CPF 802必須通知TS 804 該情況,從而可以對i某體流進行適當(dāng)?shù)拇a轉(zhuǎn)換以及路由傳送。
更具體地,圖8的體系結(jié)構(gòu)800顯示了當(dāng)設(shè)置會話時在CPF 802、TS 804、 以及終端806與808之間發(fā)生的控制流。在體系結(jié)構(gòu)800中,ARM與EVRC 音頻編解碼器之間的互操作性被處理為非限定性例子。會話的設(shè)置如下
1. 在消息810中,通過發(fā)送邀請(其中會話描述包含其所支持的音頻視 頻格式/編解碼器,例如AMR編解碼器),終端806的用戶邀請另一用戶到會 話。
2. CPF 802接收該邀請(其包含所提議的會話媒體格式/編解碼器信息以 及IP地址和端口號),并且在消息812中,請求TS 804設(shè)置代碼轉(zhuǎn)換會話, 并且提供向參加該會話的其他用戶提議的可接受格式/編解碼器的列表
3. TS 804設(shè)置代碼轉(zhuǎn)換資源,并且在消息814,將IP地址以及端口信息 與格式/編解碼器信息一起返回給CPF802。在該特定例子中,將EVRC編解 碼器添加到列表中。
4. 在消息815中,CPF 802將具有改進的媒體格式/編解碼器以及IP地址 與端口信息的邀請轉(zhuǎn)發(fā)給一皮邀請的終端808。
5. 在目的地為CPF 802的消息816中,終端808接受具有其自己支持的 解碼器(在該例子中為EVRC)的邀請。
6. 當(dāng)收到消息816時,在消息818中,CPF 802請求TS 804根據(jù)4妄受了 邀請的被邀請終端808提供的信息更新代碼轉(zhuǎn)換會話;該信息涉及已接受格
式/編解碼器,以及用于終端808的IP地址和端口 。
7. TS 804進行所請求的操作,并且消息820中,提供更新后的會話信息 給CPF 802,包括格式/編解碼器以及IP地址與端口信息。
8. 然后在消息820中,CPF 802通知終端806邀請已經(jīng)被接受以及要用 的、并且終端806支持的格式/編解碼器。
9. 然后終端806利用現(xiàn)有的PoC機制,獲得講話許可權(quán)。
10. 終端806開始向TS 804發(fā)送ARM分組。然后根據(jù)圖7的體系結(jié)構(gòu) 700, TS 804將ARM分組代碼轉(zhuǎn)換為EVRC分組,并且將其轉(zhuǎn)發(fā)給終端808。 如果替換地使用圖6的體系結(jié)構(gòu)600,則在TS 804中被代碼轉(zhuǎn)換之前,分組 首先到達CPF 802。
在以下描述的圖10中,以詳細的信令流提供了更多的細節(jié)。 現(xiàn)在參照圖9,體系結(jié)構(gòu)900當(dāng)用戶例如906請求講話許可斥又時在CPF
902、 TS904、以及用戶906與908之間發(fā)生的控制流的例子。 一般地,假設(shè)
開始沒有用戶有講話許可權(quán)。步驟如下
1. 終端906通過發(fā)出TB (講話猝發(fā))請求消息901,請求講話許可權(quán)。 在該例子中,假設(shè)圖7的媒體流動,但是本領(lǐng)域技術(shù)人員可以容易地設(shè)想用 于根據(jù)圖6的媒體流動的適當(dāng)?shù)南⒘鳌?br>
2. TB請求消息901到達TS 904,并且在消息912中被轉(zhuǎn)發(fā)給CPF 902。
3. 在消息914中,CPF 902通知TS 904用戶終端906正在請求講話許可 權(quán),從而TS904可以適當(dāng)?shù)叵鄳?yīng)分配代碼轉(zhuǎn)換資源,并且實施對々某體流的適 當(dāng)控制。
4. 在TS 904在消息916中向CPF 902確認準(zhǔn)許該請求之后,CPF 902通 過發(fā)送TB確認消息918給TS 904 ,通知用戶終端906其講話請求被準(zhǔn)許, TS卯4在消息920中將該TB確認消息918轉(zhuǎn)發(fā)給用戶終端906。
5. 然后,在^ 某體流動922中,用戶終端906可以開始發(fā)送RTP傳輸上的 AMR分組。
6. 媒體流動922到達TS 904。 TS 904將媒體信息/人AMR代碼轉(zhuǎn)換為 EVRC格式,然后在媒體流動924中,將代碼轉(zhuǎn)換的媒體發(fā)送給用戶終端908。
7. 然后,在媒體流動926中,對于媒體924的RTCP報告(例如終端908 接收的分組的數(shù)目)祐:/人終端908發(fā)送給TS卯4。
8. 在媒體流動928中,對于媒體922的RTCP報告被從TS 904發(fā)送給用
戶906。
使用AMR與EVRC編解碼器僅是為了說明在體系結(jié)構(gòu)900中要執(zhí)行的 操作,但是體系結(jié)構(gòu)900不限于此。體系結(jié)構(gòu)900可以支持各種格式/編解碼 器以及格式/編解碼器的組合,包括音頻視頻格式/編解碼器的組合,例如 AMR、 EVRC、 H.263、 MPEG-4部分2、 MPEG-4部分10等等。例如,體系
另外,在本應(yīng)用中,僅僅出于說明目的,在TS 904與CPF 902之間流動TB (請求/確認)消息。在本發(fā)明的其他修改與實施例中,對于此類操作,可以 使用IP交換機,以將此類消息直接路由傳送給CPF792,而不必經(jīng)過TS904。 2.4用于適配集中在CPF上的詳細信令流
現(xiàn)在參照圖10,描述了集中在CPF上的代碼轉(zhuǎn)換方案的詳細信令流???以考慮幾種組會話情況及其變體。但是,這將使本說明書閱讀起來非常煩瑣, 也沒有提供任何附加好處。因此,將描述配備有對應(yīng)的詳細信令流的代表性 使用情況。本領(lǐng)域技術(shù)人員可以直接方式將該信令流應(yīng)用于所有其他情況。
在下文中,將描述"利用在PoC規(guī)格中描述的手動回答命令上會話的確 認指示,,的情況。將不描述關(guān)于SIP/IP核心的信令細節(jié),這是因為本領(lǐng)域技 公知,并且只會增加流動的復(fù)雜性而沒有任何益處。另外,考慮所有i某體分 組到達TS的情況。但是,本領(lǐng)域技術(shù)人員可以直接方式考慮其都到達CPF 的情況。
圖10顯示對于代碼轉(zhuǎn)換方案集中在CPF上、并且其中所有媒體流都到 達TS的情況的、在CPF 1002、 TS 1004、用戶終端1006與1008及其相應(yīng)PPF 1010與1012之間的詳細信令流的示范性實施例1000。
0. PoC用戶1006按壓對應(yīng)PoC終端的PoC按鈕,以發(fā)起組會話。
1. 通過這樣做,在消息1014中,用戶1006發(fā)出包含SDP信息(標(biāo)記為 SDP-A )的SIP INVITE方法。SIP INVITE首先到達用戶1006的網(wǎng)絡(luò)中的PPF 1010 (例如其歸屬PPF )。例如,作為非限定性例子,SDP-A可以包括
c=IN IP6 FF1E:03AD::7F2E:172A:1E24 m= audio 3456 RTP/AVP 97 a= rtpmap: 97 AMR a= rtcp:5560
m= application 2000 udp TBCP
19
a= fmtp:TCBP queuing=l; tb_priority=2; timestamp=l
2. 然后,在消息1016中,將SIP INVITE從PPF 1010發(fā)送給CPF 1002。 CPF 1002可以在任何網(wǎng)絡(luò)上,例如用戶1006的網(wǎng)絡(luò)、用戶1008的網(wǎng)絡(luò)、或 者不同的網(wǎng)絡(luò)。
3. 然后,在消息1018中,CPF 1002聯(lián)系TS 1004設(shè)置用于該會話的代 碼轉(zhuǎn)換資源。該請求包括在SDP-A中包含的格式/編解碼器以及IP地址和端 口信息。編解碼器信息用來得知被邀請方(例如用戶1008 )的格式/編解碼器, 并且確定可以向?qū)ζ渌脩舻臅捥嶙h添加哪些附加的格式/編解碼器。IP地 址和端口信息用來確定在代碼轉(zhuǎn)換之后需要將來自其他用戶的代碼轉(zhuǎn)換的結(jié) 果發(fā)送到何處以到達發(fā)出邀請的客戶端(在這種情況下為用戶1006)。因為 所有媒體分組都到達TS 1004,所以IP地址和端口信息還用來確定需要將來 自CPF 1002講話猝發(fā)(TB)響應(yīng)發(fā)送給何方以達到用戶1006。另外,需要 CPF 1002的IP地址和端口信息,使發(fā)出邀請的客戶端(用戶1006)向其轉(zhuǎn) 發(fā)講話猝發(fā)請求。例如,如果CPF 1002的IP地址為IP6 FF1E:03AD::7F2E:172A:1E28,則如下提供使用SDP的信息(盡管4妄口不需 要使用SDP ):
c =IN IP6 FF1E:03AD::7F2E:172A:1E28 m= application 2002 udp TBCP
另外,設(shè)置代碼轉(zhuǎn)換操作一般調(diào)用兩個TSAPI (應(yīng)用程序接口 )方法 i) SetupTranscodingSession(SDP-A, SDP-CPF)以及 ii) AddInvitee(Session ID)。
i) 該第一方法發(fā)起新的代碼轉(zhuǎn)換會話。其建立新的會話ID上下文,并且 記住用來^f吏其所有i某體到達用戶1006與CPF 1002的IP地址與端口 。其還記 住用戶1006 (即發(fā)出邀請方)支持的媒體格式/編解碼器與協(xié)議。該方法返回 會話ID。在圖11中的點虛線1110中顯示了用戶1006的TS 1004內(nèi)的^f呆留處 理。
ii) 該第二方法向會話ID提供邀請新參加者信息。該方法返回用戶ID與 用戶可以向其發(fā)送i某體流、并且其中CPF 1002可以通過TS 1004向該用戶發(fā) 送TB響應(yīng)的IP地址和端口 。所有信息在會話ID的上下文中更新。
4. 然后,TS 1004將在消息1020中向CPF 1002返回以下信息 對于消息1018中的對于SetupTranscodingSession(SDP-A, SDP-CPF)的調(diào)
用,其將返回會話ID用于將來引用。
對于對AddInvitee(SessionID)的調(diào)用,其將返回(如圖11中短劃線1116 中所示)用于將來引用的用戶ID(例如接受了邀請的用戶或者離開的用戶), 在對被邀請方1008的會話提議中提供的格式/編解碼器的列表(即TS 1004 可以支持與用戶1006所提議的格式/編解碼器的代碼轉(zhuǎn)換的格式/編解碼器的 列表),其中被邀請的用戶1008可以向其他參加者發(fā)送其媒體以進行代碼轉(zhuǎn) 換的地址/輸入端口的列表,其中CPF 1002可以發(fā)送對被邀請的用戶1008的 講話猝發(fā)響應(yīng)給TS 1004的地址/輸入端口的列表。
TS 1004可以利用如下的SDP提供信息(盡管接口不需要使用SDP): i)對于邀請其他參加者
c = IN IP6 FF1E:03AD::7F2E:172A:1E30
m= audio 53456 RTP/AVP 97 98
a= rtpmap: 97 AMR
a= rtpmap: 98 EVRC/訓(xùn)0
a= rtcp:53080
m= application 50000 udp TBCP a= fmtp:TCBP queuing=l; tb_priority=2; timestamp=l 以及ii)對于從CPF 1002發(fā)送TB響應(yīng) c =IN IP6 FF 1E:03AD::7F2E: 172A: 1E30 m=application 53458 udp TBCP 請注意每次CPF 1002希望要求新用戶到會話時,其將必須調(diào)用 Addlnvitee(Session ID)。另外,如果所有媒體流都在去向TS 1004之前進入 CPF 1002 (另一選項),則步驟3 (利用消息1018)中的IP地址與端口不對 應(yīng)于SDP-A,而是對應(yīng)于CPF 1002中的IP地址與端口 。另夕卜,因為在CPF 1002 與TS 1004之間沒有TBCP的任何流動,所以在參數(shù)中不存在具有媒體TBCP 的行"m=,,。因此,TS 1004知道其不需要處理任何講話猝發(fā)控制消息 (TBCM )。
5. 從TS 1004接收的信息響應(yīng)由CPF 1002處理,并且生成修改后的邀請 SDP-A,,然后在消息1022中,通過其PPF 1012將其發(fā)送給被邀請方1008。
6. 在消息1024中,PPF 1012將收到的邀請轉(zhuǎn)發(fā)給PoC用戶1008。
7. 在消息1026中,從用戶1008向其PPF 1012發(fā)送更改(Altering)消
息。該更改消息通知發(fā)出邀請的用戶1006被邀請的用戶1008已經(jīng)收到了邀 請,但是還沒有接受邀請。
8. 然后,在消息1028中,將更改消息從PPF 1012發(fā)送到CPF 1002。
9. 然后,在消息1030中,將更改消息從CPF 1002發(fā)送到用戶1006的 PPF 1010。
10. 最后,在消息1032中,用戶1006接收PPF 1010發(fā)送的更改消息。
11. 用戶1008接受邀請,并且在消息1034中,向其PPF 1012發(fā)送 SDP-AB,中的選定媒體信息。例如,SDP-AB,可以包括
c= INIP6FF 1E:03 AD: :7F2E: 172A: 1E34 m= audio 5458 RTP/AVP 98 a= rtpmap: 98 EVRC/8000 a= rtcp: 5480
m= application 4000 udp TBCP
a= fmtp:TCBP queuing=l; tb_priority=2; timestamp=l
12. 在消息1036中,PPF 1012將消息1034轉(zhuǎn)發(fā)給CPF 1002。
13. 然后,在消息1038中,CPF 1002聯(lián)系TS 1004更新代碼轉(zhuǎn)換會話。 該請求實際涉及以下兩種TS API方法
陽Join(SessionID,UserID, SDP-AB,,SDP-CPF)(在圖11中在實線1112中 顯示)該方法通知TS 1004用戶1008已經(jīng)接受了邀請。其通過記住對應(yīng)于 用戶ID以及CPF 1002的用來使其所有々某體翁:據(jù)到達用戶1008的IP地址與 端口,更新會話ID上下文。其還記住用戶ID (即參加方1008)所支持的媒 體格式/編解碼器。例如,CPF 1002必須提供關(guān)于其IP地址與端口的信息, 來自用戶ID的TB請求可以向該IP地址與端口發(fā)送 c =IN IP6 FF1E:03AD::7F2E:172A:1E28 m= application 2008 udp TBCP 在圖11中在實線1112中顯示了對于用戶1008的TS 1004內(nèi)部的保留處理。
-AcceptInvite(Session ID, SDP畫AB,, SDP-CPF):該方法通知TS 1004來自 用戶1006的邀請已經(jīng)被至少一個人接受。其通過記住對于每個輸入端口希望 用戶1006使用哪些格式/編解碼器,更新會話ID上下文。該方法返回其中用 戶1006可以發(fā)送媒體流的、以及CPF 1002可以沿其通過TS 1004向用戶1006
發(fā)送TB響應(yīng)的IP地址與端口。在圖11中在長劃線1114中顯示了對于用戶 1006的TS 1004內(nèi)部的保留處理。
14. 然后在消息1040中,TS 1004向CFP 1002返回以下信息
在消息1038中進行的調(diào)用Join(Session ID, User ID, SDP-AB,, SDP-CPF) 的請求的狀態(tài)。通常,該狀態(tài)報告成功地將新用戶添加到會話,或者沒有添 加該新用戶的原因。
在消息1038中進行的調(diào)用Acceptlnvite(Session ID, SDP-AB,, SDP-CPF) 的返回參數(shù),包括其中用戶1006可以發(fā)送其々某體流以代碼轉(zhuǎn)換為其他參加 者的格式的地址/輸入端口的列表,要使用的格式/編解碼器,其中CPF 1002 可以向TS 1004發(fā)送對于用戶1006的講話猝發(fā)響應(yīng)的地址/輸入端口的列表。 TS 1004將利用如下SDP提供信息,在圖11中在長劃線1114中顯示(盡管 接口不需要使用SDP):
i) 對于在會話期間向用戶1006發(fā)送數(shù)據(jù) c=IN IP6 FF1E:03AD::7F2E:172A:1E3 m= audio 48456 RTP/AVP 97
a= rtpmap: 97 AMR a= rtcp: 48080
m= application 48000 udp TBCP
a= fmtp:TCBP queuing=l; tb_priority=2; timestamp=l
ii) 對于發(fā)送來自CPF 1002的TB響應(yīng) c=IN IP6 FF1 E:03AD::7F2E: 172A: 1E30 m= application 48400 udp TBCP
15. 來自TS 1004的信息響應(yīng)由CPF 1002處理,然后在消息1042中, CPF 1002通過其PPF 1010發(fā)送對于發(fā)出邀請的一方1006的修改后的邀請 SDP-AB*。其基本包含要使用的媒體格式/編解碼器,以及其中發(fā)送媒體流的 IPJ也址與端口。
16. 在消息1044中,PPF 1010將該邀請轉(zhuǎn)發(fā)給PoC用戶1006。
17. 在消息1046中,CPF 1002通知TS 1004用戶1006具有講話許可權(quán)。 這可以利用以下API方法來進行TalkBurstInform(Session ID, User ID)。在會 話ID的上下文中更新信息。
18. TS 1004通過向CPF 1002發(fā)送消息1046,確iU亥許可斗又。
19. 在消息1050中,CPF 1002通過其PPF 1010發(fā)送目的地為用戶1006 的講話猝發(fā)確認。
20. 在消息1052中,PPF IOIO發(fā)送講話猝發(fā)確認給用戶1006。
21. 在通知1054中,授予用戶1006講話的權(quán)利。
22. 在消息1056中,CPF 1002通過其PPF 1012發(fā)送接收講話猝發(fā)消息 給用戶1008。
23. 在消息1060中,PPF 1012將接收講話猝發(fā)消息轉(zhuǎn)發(fā)給用戶1008。
24. 在通知1062中,通知用戶1008已經(jīng)授予用戶1006講話的權(quán)利。
25. 在々某體流動1064中,々某體流從用戶1006向TS 1004流動。在該示范 性實施例中,發(fā)送AMR分組。容易設(shè)想媒體流穿過CPF 1002而非TS 1004 的情況。會話發(fā)起處理(SIP)需要做的就是向用戶提供不同的地址與端口, 其將指向CPF 1002而非TS 1004,以及向TS 1004提供CPF 1002的IP地址 與端口作為輸出目的地。
26. 然后,TS 1004知道用戶1006具有講話的權(quán)利,并且在操:作1066 中,將々某體流/人AMR代碼轉(zhuǎn)換為EVRC。
27. 然后,在i某體流動1068中,TS 1004向用戶1008發(fā)送代碼轉(zhuǎn)換為 EVRC的分組。
28. 用戶釋》文PoC4姿鈕。
29到41.剩余步驟為通常PoC操作,不需要進一步解釋,其涉及代碼轉(zhuǎn) 換用戶終端1006發(fā)送的最后分組,以及結(jié)束i某體流傳送,其由講話猝發(fā)空閑 通知指示,在用戶1006釋放PoC按鈕之后。
但是,隨后由用戶1006與1008之一重新按壓PoC按鈕將如以上所述地 處理,例如通過圖10的操作1046 (利用來自希望發(fā)送媒體流用戶的講話猝 發(fā)通知)到1076 (用于發(fā)送和代碼轉(zhuǎn)換々某體流),以允許所述的一個用戶將 媒體流傳送給(多個)其他參加者。操作1070到1094描述了當(dāng)所述一個用 戶釋放PoC按鈕時在信令流中發(fā)生的情況。
圖11的々某體流動體系結(jié)構(gòu)IIOO顯示了在代碼轉(zhuǎn)換方案集中在CPF 1102 上的情況下通過CPF 1102與TS 1104的媒體流動的路由傳送。用于從發(fā)出邀 請的終端1106發(fā)出的+某體的TS 1102上的輸入IP地址與端口 、以及從CPF 1102到終端1106的TBCP消息在長劃線1114中顯示。來自終端1106的輸入 IP地址與端口被映射到各種類型的媒體流動,例如編解碼器、RTCP以及
TBCP,如在i某體流動1114中所示。類似地,用于從被邀請的終端1108發(fā)出 的i某體的TS 1102上的輸入IP地址與端口 、以及從CPF 1102到終端1108的 TBCP消息在短劃線1116中顯示。來自終端1108的輸入IP地址與端口^^映 射到各種類型的媒體流動,例如編解碼器、RTCP以及TBCP,如在媒體流動 1116中所示。用于要發(fā)送給發(fā)出邀請的終端1106的媒體的TS 1102上的目的 地IP地址與端口 、以及/人終端1106到CPF 1102的TBCP消息在點劃線1110 中顯示。終端1106上的輸入IP地址與端口被映射到各種類型的々某體流動, 例如編解碼器、RTCP以及TBCP,如在々某體流動1110中所示。
用于要發(fā)送給被邀請的終端1108的媒體的TS 1102上的目的地IP地址 與端口 、以及用于來自終端1108的目的地為CPF 1102的TBCP消息的IP地 址與端口在圖ii中在實線1112中顯示。終端1108上的輸入IP地址與端口 被映射到各種類型的媒體流動,例如編解碼器、RTCP以及TBCP,如在媒體 流動1112中所示。應(yīng)該注意TS 1102具有IP地址,在該例子中,其以"1E30" 結(jié)束,并且用于1114與1116中顯示的所有進入的媒體流動,盡管對于每個 不同的流動使用不同的端口。對于外出的流動,以"1E24"結(jié)束的IP地址目 的地為終端1106,以"1E28,,結(jié)束的IP地址目的地為CPF 1102,并且以"1E34" 結(jié)束的IP地址目的地為終端1108。
需要注意對所述示范性事實例的某些進一步的解釋以及變化 -多個參加者的情況在這種情況下,對于每個要邀請的參加者,CPF 1102 將必須在發(fā)送SDP INVITE之前調(diào)用Addlnvitee(Session ID),并且一旦用戶接 受了則必須調(diào)用Join(Session ID, User ID, SDP-AB,, SDP-CPF)。當(dāng)參加者離開 會話時,考慮到離開會話的用戶ID, CPF 1102必須調(diào)用Leave(Session ID, User ID),其更新會話ID。
-所有媒體分組到達CPF 1102的情況該替換情況在以上參照圖IO討論。 會話發(fā)起處理要做的就是向用戶提供不同的地址與端口 ,其指向CPF 1002而 非TS 1004,并且向TS 1004提供CPF 1002 IP地址與端口作為輸出目的地。 另外,當(dāng)向TS 1004提供媒體信息時,會話描述中沒有TBCP媒體部分,這 是因為其完全由CPF 1002管理。應(yīng)該注意,這是PoC應(yīng)用中假設(shè)的"安全" 情況,如在[1]9.12小節(jié)中所述,其中所有的i某體流動必須經(jīng)過CPF 1002 (由 于分組復(fù)制)。但是,另一情況(其中所有的媒體流達到TS)效率高得多、 擴展性強得多,因為其將々某體處理分派給了 TS 1004。在某種意義上,可以把TS 1004當(dāng)作CPF 1002的擴展。
請注意可以對上述示范性實施例進行許多變化,而不會脫離本發(fā)明的 性質(zhì)與范圍。例如,在一種變化中,TBCP消息可以不流經(jīng)TS 1004??梢詫?TS行為分類為嚴格控制的或者松散控制的。當(dāng)嚴格控制時,TS 1004或者監(jiān) 控TBCP消息,以確定誰有講話許可權(quán),或者從CPF 1002接收特定控制消息。 當(dāng)松散控制時,TS 1004通過監(jiān)控媒體流獲得,知道誰在講話。也可以修改 CPF 1002與TS 1004之間的特定方法與API,而不會脫離本發(fā)明的范圍。另 外,諸如PPF 1006、 CPF 1002、以及TS 1004等媒體元素被顯示為不同的邏 輯元素,但是在實踐中,其中之一或者多個可以被組合在一起,成為單個服 務(wù)器,而不會脫離本發(fā)明的范圍。
3.其中代碼轉(zhuǎn)換方案在被邀請的參力。PoC功能上的PoC信令流
該小節(jié)提供本發(fā)明的第二非限定性示范實施例,其中在被邀請方的PPF 上進行代碼轉(zhuǎn)換。
參加與控制PoC功能的角色
在其中在被邀請PPF上進行代碼轉(zhuǎn)換的情況下,整個代碼轉(zhuǎn)換處理由 PPF管理,同時講話許可權(quán)以及將々某體流路由傳送到每個目的地(包括復(fù)制 媒體分組)仍然由CPF管理。不管所建立的組會話的類型如何,PPF都具有 兩種主要責(zé)任,其基本上與在2.1中描述的相同。首先PPF保證在用戶之間 的適當(dāng)?shù)臅捥嶙h以及設(shè)置。第二, PPF管理用戶與CPF之間的媒體流的流 動。應(yīng)該注意,雖然所有的媒體流都必須穿過CPF,但是它們不需要穿過所 有的PFF。但是,會話控制消息必須穿過所有的PPF與CPF。
CPF的角色為i)控制誰有講話許可權(quán);以及ii)復(fù)制以及路由傳送講 話用戶的媒體分組到其他用戶。
當(dāng)前情況與其中代碼轉(zhuǎn)換方案集中在CPF上的情況之間的主要差異在
于
i) PPF將控制用戶與CPF之間的代碼轉(zhuǎn)換(因此有一個用戶在輸入端, 并且有一個用戶在輸出端),而在先前情況下,CPF必須控制到所有目的地(許 多用戶)的代碼轉(zhuǎn)換。這是因為不允許PPF復(fù)制分組到各個目的地;復(fù)制只 有由CPF進行。
ii) PPF不必控制誰講話;CPF仍然控制誰講話。因此可以兩種方式進行PFF對代碼轉(zhuǎn)換服務(wù)器的控制a)松散控制---旦設(shè)置會話,代碼轉(zhuǎn)換服
務(wù)器總是有效,并且總是準(zhǔn)備進行代碼轉(zhuǎn)換,但是某些信道可能會空閑;b) 嚴格控制一一PPF將監(jiān)聽TBCM,并且通知代碼轉(zhuǎn)換服務(wù)器開始或者停止代 碼轉(zhuǎn)換,可替換地,PPF可以分析TBCM,并且確定誰有講話許可權(quán)。
在本發(fā)明的該第二非限定性示范實施例中,在被邀請的參加者的PPF上 進行適配或者代碼轉(zhuǎn)換。發(fā)出邀請的終端向其他方發(fā)送邀請,該邀請包含其 媒體會話描述。每個被邀請的參加者的PPF都將進行與圖8中CPF所進行的 相同的操作。這會導(dǎo)致以下情況發(fā)出邀請一方的PPF不需要進行代碼轉(zhuǎn)換, 這是參加會話的其他各方(例如被邀請的用戶)的PPF的責(zé)任。因此,在CPF 內(nèi)將流動發(fā)出邀請一方所支持格式的媒體。如果參加會話的許多被邀請方支 持發(fā)出邀請 一 方的媒體格式,則可以減少系統(tǒng)中代碼轉(zhuǎn)換所需的計算資源。
圖12顯示了用于在被邀請方的PPF上的代碼轉(zhuǎn)換的示范性體系結(jié)構(gòu) 1200。在情況A)中,在接收PPF進行代碼轉(zhuǎn)換。發(fā)出邀請的終端1202 (其
此類流(為發(fā)出邀請的終端1202所支持的、并且在會話建立時同意的格式) 在CPF 1204內(nèi)流動。被邀請方的PPF 1214與1216接收終端1202所支持格 式的媒體流,然后按照需要對其進行代碼轉(zhuǎn)換,以滿足被邀請終端1212與 1210的能力。在該例子中,對于用戶1212, PPF 1214形成TS,其將收到的 媒體流從ARM代碼轉(zhuǎn)換為EVRC,而對于用戶1210, PPF 1216不必進行任 何代碼轉(zhuǎn)換,因為用戶1210的終端已經(jīng)支持ARM。
應(yīng)該注意,在該例子中,元素1202、 1212、以及1214每個都形成融入 單個服務(wù)器中的PFF與TS的組合。
另外,如圖12所示,情況B)對應(yīng)于其中代碼轉(zhuǎn)換發(fā)生在發(fā)送與接收 PPF上的情況。用戶1224發(fā)起組會話,并且邀請用戶1232與1220參加。被 邀請的用戶1220具有講話許可權(quán)。PPF 1222將媒體流動乂人用戶1120支持的 格式代碼轉(zhuǎn)換為發(fā)出邀請的終端1224支持、并且在會話建立期間同意的格 式。例如,PPF 1222進行從EVRC到ARM到的代碼轉(zhuǎn)換,因為AMR為發(fā) 出邀請的終端1224所支持、并且在會話建立期間同意的格式,并且由此在 CPF 1226內(nèi)流動。發(fā)出邀請的終端1224的PPF 1228不進行代碼轉(zhuǎn)換。PPF 1230—般為被邀請的終端1232進行代碼轉(zhuǎn)換。但是,因為CPF 1226提供的 媒體流動處于被邀請的終端1232所支持的格式,所以PPF 1230確定不需要
進行代碼轉(zhuǎn)換。實際上,因為終端1232支持對于終端1224在會話建立期間 同意的、并且在CPF 1226內(nèi)流動的相同格式/編解碼器,所以在終端1232上 不需要進行去向以及來自終端1232的代碼轉(zhuǎn)換,而不管誰在講話。例如,在 該例子中,AMR總是在CPF 1222內(nèi)流動,并且因為ARM也被終端1232支 持,所以PPF 1230必須不進行代碼轉(zhuǎn)換。再次地,元素1222、 1228、以及 1230每個都形成融入單個服務(wù)器中的PFF與TS的組合。
在剩余說明書中,將被發(fā)出邀請的終端所支持、并且在會話建立期間同 意(由此在CPF內(nèi)流動)的格式稱為"公共流格式"(CSF)。
3.2參加PoC功能管理的業(yè)務(wù)的類型與媒體流動
對于々某體流動,與其中代碼轉(zhuǎn)換方案集中在CPF上的情況類似,考慮兩 種方案,如圖6與圖7所示,但是具有以下^f務(wù)改替代CPF 602或者702, PPF與TS 604或者704交互。除TS與PPF而非CPF交互之外,主要區(qū)別在 于到達PPF或者TS的TB請求將被轉(zhuǎn)發(fā)給CPF,并且TB響應(yīng)在到達PPF或 者TS之前來自CPF。
3.3參加PoC功能管理的會話控制
PPF具有非常少的會話管理責(zé)任。例如,與CPF不同,本地PPF不需要 關(guān)心新用戶是否假如或者離開會話,只要會話仍然在進行,并且其所服務(wù)的 用戶仍然在參加即可,這是因為對于給定用戶,其僅管理來自以及去向CSF 的代碼轉(zhuǎn)換。另外,其不需要管理誰有講話許可權(quán);在最差的情況下,其僅 監(jiān)控這一點。
因此,圖8的會話流以及圖9的控制流仍然對本情況適用,只是TBCM 還被路由傳送去向/來自CPF ,并且TS將被凈皮邀請方的PPF替代。 3.4對于集中在PPF上的適配的詳細的4言令流
對于在PPF上進行代碼轉(zhuǎn)換的情況下的詳細信令流非常類似于代碼轉(zhuǎn)換 集中在CPF上的情況。圖IO保持相同,只是與代碼轉(zhuǎn)換服務(wù)器的交互將在 每個被邀請方的PPF上處理。規(guī)則為每個被邀請終端的PPF必須進行來自/ 去向該終端的所支持的媒體格式去向/來自CSF的代碼轉(zhuǎn)換。這也要求被邀請 方的PFF改變會話描述,以允許建立會話。這以與圖10中的CPF 1002所作 的相同的方式進行。對TS 1004的功能調(diào)用也類似。
4.透明PoC代碼轉(zhuǎn)換
該小節(jié)描述本發(fā)明的第三非限定性示范實施例,其中代碼轉(zhuǎn)換為透明 PoC代碼轉(zhuǎn)換。透明PoC代碼轉(zhuǎn)換指PoC終端與服務(wù)器不知道正在發(fā)生代碼 轉(zhuǎn)換,并且所做就如任何常規(guī)PoC實體在沒有進行代碼轉(zhuǎn)換的上下文中所做 的那樣。代碼轉(zhuǎn)換服務(wù)器被作為代理插入在通信路徑中。該方法的主要優(yōu)點
在于其不需要對現(xiàn)有的PoC終端與服務(wù)器進行任何改變。實際上,已經(jīng)部署 了 PoC系統(tǒng)的運營商可以添加PoC代碼轉(zhuǎn)換,而不對已經(jīng)部署的PoC終端與
服務(wù)器進行任何改變。該方法已經(jīng)被證明能夠有效地在多媒體消息服務(wù)中順 利引入代碼轉(zhuǎn)換。
4.1集中在CPF上的透明PoC代碼轉(zhuǎn)換
在該實施例中,將代碼轉(zhuǎn)換服務(wù)器(TS)置于網(wǎng)絡(luò)的中心位置,從而其 與CPF位置相同,并且可以因此利用以該特有方式相對于CPF放置這一點。 在媒體路徑中,將TS置于CPF之后,但是在會話控制路徑中,將TS置于 CPF之前。另外,所有媒體分組(通常媒體與TBCP)都穿過CPF,其在媒 體流流動中位于TS之前。
圖13的體系結(jié)構(gòu)顯示了 CPF 1302上的透明代碼轉(zhuǎn)換的示范體系結(jié)構(gòu)。 處于媒體路徑中的CPF 1302將復(fù)制通常的(多個)進入々某體流,并且試圖將 其分發(fā)給會話中的其他用戶。這些輸出流每個都進入TS 1304,并且將分別按 照需要被代碼轉(zhuǎn)換,以滿足目的地終端能力,并且此后將其分發(fā)給每個目的 地終端1306與1308。 TBCP分組也將進入TS 1304, TS 1304將其轉(zhuǎn)發(fā)給其 目的地。或者通過監(jiān)控從CPF 1302發(fā)送的TCBP分組的內(nèi)容,或者通過識別 進入的通常媒體流(其是無效的,因為正在講話的用戶是對其CPF 1302沒有 沒有傳送々某體流的用戶),TS 1304可以了解誰有講話許可權(quán)。根據(jù)這一點, TS 1304將確定對每個目的地進行的代碼轉(zhuǎn)換操作。例如,如果正在講話的人 使用AMR編解碼器,則對于支持EVRC編解碼器的用戶,需要進行ARM到 EVRC代碼轉(zhuǎn)換;但是如果正在講話的人使用EVRC編解碼器而不是AMR 編解碼器,則不需要代碼轉(zhuǎn)換。
另外,在圖13中,CPF 1302對于所有的目的地用戶復(fù)制從用戶1310獲 得的AMR流。TS 1304截獲那些々某體流,并且將其代碼轉(zhuǎn)換以適合目的地用 戶1306與1308的能力,并且將代碼轉(zhuǎn)換的々某體流發(fā)送給其目的地。由此, 進入TS 1304的目的地為終端1306的AMRJ某體在TS 1304的輸出端變?yōu)閷?于終端1306的EVRC ^某體,而在TS 1304的輸入端上目的地為終端1308的AMR媒體在TS 1304的輸出端保持為對于終端1308的AMR媒體。TS 1304 還將未改變的TBCP消息轉(zhuǎn)發(fā)每個目的地用戶1306與1308。
要使媒體流穿過CPF 1302然后通過TS 1304,在會話建立處理期間,必 須進行某些SDP修改。關(guān)于向哪里發(fā)送信息,將TS 1304的IP地址和端口信 息給予CPF 1302。將CPF 1302的IP地址和端口信息給予用戶,而不管向哪 里發(fā)送信息。TS 1304管理這些IP地址、端口集合與不同實體希望從其接收 其數(shù)據(jù)的地點之間的連接。
圖14顯示對于透明代碼轉(zhuǎn)換集中在CPF 1402上的情況的、在CPF 1402、 TS 1404、以及終端1405和1406之間的詳細信令流的示范實施例。沒有顯示 終端1405和1406的PPF,以簡化描述,但是不喪失一4殳性。在下文中,描 述在重新確定力某體流的路由程序中從CPF 1402到TS 1404的會話提議變化 (例如提議的格式/編解碼器)。信令流如下
1. 在操作1410中,PoC用戶1405按壓PoC按鈕,以發(fā)起組會話。
2. 在消息1412中,PoC用戶1405發(fā)出包含利用SDP信息的會話描述的 SIP INVITE方法。SIP INVITE被TS 1404截獲,TS 1404可以例如位于與CPF 1402相同的網(wǎng)絡(luò)中。例如,SDP-A可以包括
c = INP6 FF1E:03AD::7F2E:172A:1E24 m=audio 3456 RTP/AVP 97 a= rtpmap: 97 AMR a= rtcp:5560
m= application 2000 udp TBCP
a= fmtp:TCBP queuing=l; tb_priority=2; timestamp=l
3. TS 1404改變用戶1405提供的格式/編解碼器以及IP地址和端口信息, 從而目的地為用戶1405的任何々某體流都在被傳送給用戶1405之前,首先到 達TS 1404 (參見圖15中的點線)。其還存儲新提議的SDP與用戶開始提議 的SDP之間的綁定信息。另外,TS 1404通過添加其可以支持來自與去向用 戶1405提議的媒體格式/編解碼器的代碼轉(zhuǎn)換的媒體格式/編解碼器,來改進 會話描述。然后,在消息1414中,TS 1404向CPF 1402發(fā)送具有更新的SDP 會話描述的邀請。例如,TS 1404提供的SDP可以為
c=IN IP6 FF1E:03AD::7F2E:172A:1E30 m= audio 18456 RTP/AVP 97 98a=rtpmap: 97 A歐
a= rtpmap: 98 EVRC/8000
a=rtcp: 18080
m= application 18000 udp TBCP a= fmtp:TCBP queuing=l; tb_priority=2; timestamp=l 請注意在行"c-"中將IP地址從用戶1405替換為TS 1404,并且在行"a-" 中添加了 EVRC編解碼器。
4. CPF 1402接收SDP會話描述,對其進行修改從而使媒體流首先經(jīng)過自 己。然后,在消息1416中,CPF 1402將修改后的邀請發(fā)送給用戶1406。 CPF 1402還知道IP地址與端口的映射,因此其可以將進入的分組轉(zhuǎn)發(fā)給正確的目 的地。例如,其可以如圖15所示(參見短劃線)
c =IN IP6 FF1E:03AD::7F2E:172A:1E28 m= audio 53456 RTP/AVP 97 98 a= rtpmap: 97 AMR a=rtpmap: 98 EVRC/8000 a= rtcp:53080
m= application 50000 udp TBCP
a= fmtp:TCBP queuing=l; tb_priority=2; timestamp=l
5. 更改消息1418被從用戶1406發(fā)送給TS 1404。
6. 更改消息1420 ^皮/人TS 1404發(fā)送給CPF 1402。
7. 更改消息1422被從CPF 1402發(fā)送給用戶1405。
8. 用戶1406接受邀請,并且在消息1424中,在SDP-AB,中提供選定媒 體信息。該請求由TS 1404截獲。例如,SDP-AB,可以包括
c=IN IP6 FF1E:03AD::7F2E:172A:1E34 m=audio 5458 RTP/AVP 98 a=rtpmap: 98 EVRC/8000 a=rtcp: 5480
m= application 4000 udp TBCP
a=fmtp:TCBP queuing=l; tb_priority=2; timestamp=l
9. TS 1404保留代碼轉(zhuǎn)換資源與端口 ,并且在消息1426中,向CPF 1402 提供修改后的SDP會話。例如,該SDP可以為c=IN IP6 FF1E:03AD::7F2E:172A:1E30 m= audio 28456 RTP/AVP 97 a= rtpmap: 97 AMR a= rtcp: 28080
m= application 28000 udp TBCP
a= fmtp:TCBP queuing=l; tb_priority=2; timestamp=l
10. 該信息響應(yīng)被CPF 1402進一步修改,以將其自己首先包括在媒體路 徑中。然后,在消息1428中,CPF 1402將修改后的響應(yīng)發(fā)送給用戶1405。 例如,該SDP可以為
c=INIP6 FF1E:03AD::7F2E:172A:1E28
m=audio 48456
a= rtpmap: 98 EVRC/8000
a= rtcp:48080
m= application 48000 udp TBCP
a= fmtp:TCBP queuing=l; tb_priority=2; timestamp=l
11. 在消息1430中,CPF 1402發(fā)起對于用戶1405的"講話猝發(fā)確認" 消息,該消息到達TS 1404 (因為其是媒體路徑中CPF 1402之后的下一個)。
12. 在消息1432中,將"講話猝發(fā)確認"消息從TS 1404發(fā)送給用戶1405。
13. 在通知1434中,將"講話進行"通知發(fā)送給用戶1405。
14. 在通知1436中,從用戶1408接收"講話猝發(fā)",將其從CPF 1402 向用戶1406發(fā)起,并且到達TS 1404,這是因為其是媒體路徑中CPF 1402 之后的下一個。
15. 在通知1438中,從用戶1405接收"講話猝發(fā)",將其從TS 1404發(fā) 送給用戶1406。
16. 在通知1440中,將"講話者ID"通知發(fā)送i合用戶1406。
17. 在來自用戶1405的流動中發(fā)送的i某體分組達到CPF 1402,這是因為 其為々某體路徑中的第一個(參見圖15中的長劃線)。
18. CPF 1402按照需要復(fù)制收到的媒體流,并且在媒體流動1444中,將 復(fù)制的媒體流轉(zhuǎn)發(fā)給TS 1404。
19. 在操作1446中,TS 1404代碼轉(zhuǎn)換流。
20. 在媒體流動1448中,TS 1404將適配和代碼轉(zhuǎn)換的媒體流轉(zhuǎn)發(fā)給用
戶1406。
21.剩余的信令流就明白了。當(dāng)用戶1406講話時,從用戶1406到用戶 1408的i某體流動在圖15中在短劃線和點線中顯示。
當(dāng)會話中涉及多個終端時,對于每個參加終端,以類似的方式(從而CPF 1402為路徑中的第一個,并且TS 1404為下一個),CPF 1402與TS 1404進 行SDP》務(wù)改,以^修改i某體流的3各徑。CPF 1402與TS 1404也都知道哪些IP 地址和端口屬于哪個會話描述,以進行正確的代碼轉(zhuǎn)換和路由傳送。
請注意,重要的是,雖然在媒體流動中CPF 1402在TS 1404之前,但是 在會話流動中,TS 1404總是在CPF 1402之前。通過在網(wǎng)絡(luò)中使用IP交換機 從而不是來自TS 1404的、以CPF 1402為目的地的每個SIP分組被路由傳送 給TS 1404,可以保證這一點。實際上,以CPF 1402為目的地的每個會話控 制消息首先穿過TS 1404 , TS 1404可以修改其內(nèi)容。
最后,圖15顯示在代碼轉(zhuǎn)換會話設(shè)置期間在CPF 1502、 TS 1506、以及 終端1502和1508之間的IP地址的路由傳送的例子。對CPF 1502的進入的 業(yè)務(wù)具有以"1E28"結(jié)束的IP地址。對TS 1506的進入的業(yè)務(wù)具有以"1E30" 結(jié)束的IP地址。并且從TS 1506外出的、目的地為終端1508的業(yè)務(wù)具有以 "1E24"結(jié)束的IP地址。關(guān)于從TS 1506外出的、目的地為終端1502的業(yè) 務(wù),該外出的業(yè)務(wù)使用以"1E34"結(jié)束的IP地址。
本領(lǐng)域技術(shù)人員在此處描述的對于體系結(jié)構(gòu)以及信令流的幾個可替換實 現(xiàn)的教導(dǎo)下,可以設(shè)想許多修改以及本發(fā)明的其他實施例。因此,應(yīng)該理解, 本發(fā)明不限于所公開的特定實施例,并且所述修改與其他實施例要包含在權(quán) 利要求的范圍內(nèi)。雖然此處采用了特定的術(shù)語,但是使用這些術(shù)語是為了說 明在PoC服務(wù)范圍中的實現(xiàn),而不是要以任何方式限定本發(fā)明的范圍。
雖然通過非限定性示范實施例上以上說明書中描述了本發(fā)明,但是在權(quán) 利要求的范圍內(nèi),可以對這些實施例進行修改,而不會脫離本發(fā)明的精神與 實質(zhì)。 參考資料 開》文移動聯(lián)盟,"Push to Talk Over Cellular (PoC) - Architecture. OMAAD-PoC-VI —0-20041117-D."3GPP TS 26.235, "Packet switched conversational multimedia applications; Default codecs (Release 6)."3GPP2 S.R0100—0, "Push to Talk Over Cellular (PoC) System Requirements."3GPP TS 23.228, "IP Multimedia Subsystem (IMS); Stage 2."3GPP TS 24. 229, "IP Multimedia Call Control based on SIP and SDP; Stage 3."3GPP2 X. S0013. 2, "IP Multimedia Subsystem (IMS); Stage 2."3GPP2 X. S0013.4, "IP Multimedia Call Control Protocol, Based on SIP and SDP stage 3." 3GPP TS 23, 218, "Multimedia (IM) session handling; stage 2." IETF RFC 3435, "Media Gateway Control Protocol; version 1." IETF RFC 3525, "Gateway Control Protocol; version 1." ITU Recommendation H.248, "Gateway control protocol." E. Burger and Guy Redmill, "Media Services in the IMS: Evolution for Innovation, " "rooKrowt力rec力/ o/c^/, May 2005. IETF RFC 2327, "SDP: Session Description Protocol."開力文移動聯(lián)盟,"Push to Talk Over Cellular (PoC) - Control Plane Document. 0MA-TS-PoCControlPlane-V1 — 0."開i丈移動聯(lián)盟,"Push to Talk Over Cellular (PoC) — User Plane. OMA-TS—PoC—UserPlane-Vl_0."
權(quán)利要求
1. 一種用來建立在具有非兼容媒體特性的終端之間的、具有會話描述的多用戶通信會話的方法,該方法包括邀請具有非兼容媒體特性的終端的用戶參加所述通信會話;設(shè)置代碼轉(zhuǎn)換會話,使之能夠根據(jù)關(guān)于接受了邀請的用戶的終端的信息,進行所述終端的非兼容媒體特性之間的代碼轉(zhuǎn)換,所述信息包含該用戶的終端的媒體特性;根據(jù)所述代碼轉(zhuǎn)換會話,建立所述會話描述;以及在所述通信會話期間,利用參加所述通信會話的其他用戶的終端的媒體特性,根據(jù)所述代碼轉(zhuǎn)換會話,對來自一個用戶的終端的媒體流進行代碼轉(zhuǎn)換,并且根據(jù)所述會話描述,將代碼轉(zhuǎn)換的媒體流發(fā)送給所述其他用戶。
2. 如權(quán)利要求l所述的方法,其中所述邀請具有非兼容媒體特性的終端 的用戶參加通信會話包括從第 一用戶向中心網(wǎng)絡(luò)元件發(fā)送具有所述會話描 述的邀請請求。
3. 如權(quán)利要求2所述的方法,其中所述會話描述包括對第一用戶的終端所支持的至少 一 個々某體特性的描述。
4. 如權(quán)利要求3所述的方法,其中所描述的所支持的々某體特性為特定編 解碼器。
5. 如權(quán)利要求2所述的方法,其中所述設(shè)置代碼轉(zhuǎn)換會話包括從所述 中心網(wǎng)絡(luò)元件接收通過代碼轉(zhuǎn)換服務(wù)器設(shè)置所述代碼轉(zhuǎn)換會話的請求。
6. 如權(quán)利要求5所述的方法,其中所述設(shè)置代碼轉(zhuǎn)換會話進一步包括 建立代碼轉(zhuǎn)換資源以及經(jīng)過所述代碼轉(zhuǎn)換服務(wù)器的々某體流流動。
7. 如權(quán)利要求6所述的方法,其中所述建立代碼轉(zhuǎn)換資源包括提供包含 以下元素中的至少一個元素的代碼轉(zhuǎn)換會話信息會話標(biāo)識、所述代碼轉(zhuǎn)換 服務(wù)器支持代碼轉(zhuǎn)換的格式與編解碼器的列表、以及允許媒體流流經(jīng)所述代 碼轉(zhuǎn)換服務(wù)器的IP地址與端口的列表。
8. 如權(quán)利要求7所述的方法,其中所述設(shè)置代碼轉(zhuǎn)換會話使之能夠根據(jù) 接受了邀請的用戶提供的信息進行非兼容媒體特性之間的代碼轉(zhuǎn)換進一步包 括利用接受了邀請的用戶的終端的會話標(biāo)識、IP地址與端口、以及格式與 編解碼器,更新所述代碼轉(zhuǎn)換會話信息。
9. 如權(quán)利要求8所述的方法,其中所述更新代碼轉(zhuǎn)換會話信息進一步包 括根據(jù)每個接受了邀請的用戶提供的信息,更新所述代碼轉(zhuǎn)換資源以及所 述經(jīng)過所述代碼轉(zhuǎn)換服務(wù)器的媒體流流動。
10. 如權(quán)利要求9所述的方法,其中所述更新代碼轉(zhuǎn)換資源以及媒體流 流動包括確定要執(zhí)行的代碼轉(zhuǎn)換操作以及代碼轉(zhuǎn)換的々某體流要送往的端口 和IPi也址。
11. 如權(quán)利要求8所述的方法,其中所述建立會話描述包括根據(jù)更新 的代碼轉(zhuǎn)換會話信息,更新所述會話描述。
12. 如權(quán)利要求6所述的方法,其中所述建立媒體流流動包括建立講 話猝發(fā)分組與々某體分組流動。
13. 如權(quán)利要求12的方法,其中所述講話猝發(fā)分組包括所述用戶與中 心網(wǎng)絡(luò)元件之間的講話請求與響應(yīng)。
14. 如權(quán)利要求13的方法,包括向所述代碼轉(zhuǎn)換服務(wù)器提供所有媒體 流流動。
15. 如權(quán)利要求14的方法,其中所述媒體分組在所述代碼轉(zhuǎn)換服務(wù)器上 進行代碼轉(zhuǎn)換,并且所述講話猝發(fā)分組被轉(zhuǎn)發(fā)給所述中心網(wǎng)絡(luò)元件。
16. 如權(quán)利要求14的方法,進一步包括向所述中心網(wǎng)絡(luò)元件提供所有 媒體流流動。
17. 如權(quán)利要求16的方法,其中只有所述媒體分組被轉(zhuǎn)發(fā)給所述代碼轉(zhuǎn) 換服務(wù)器進行代碼轉(zhuǎn)換。
18. 如權(quán)利要求6的方法,進一步包括通過所述中心網(wǎng)絡(luò)元件,管理 所述纟某體流流動、通信會話流動、以及代碼轉(zhuǎn)換程序。
19. 如權(quán)利要求18的方法,其中所述代碼轉(zhuǎn)換程序進一步由用戶終端所 在的本地網(wǎng)絡(luò)管理,并且講話許可權(quán)由所述中心網(wǎng)絡(luò)元件管理。
20. —種用來建立在具有非兼容々某體特性的終端之間的、具有會話描述 的多用戶通信會話的系統(tǒng),該系統(tǒng)包括用來邀請具有非兼容媒體特性的終端的用戶參加所述通信會話的部件; 用來設(shè)置代碼轉(zhuǎn)換會話,使之能夠根據(jù)關(guān)于接受了邀請的用戶的終端的信息,進行所述終端的非兼容媒體特性之間的代碼轉(zhuǎn)換的部件,所述信息包含該用戶的終端的i某體特性;用來根據(jù)所述代碼轉(zhuǎn)換會話,建立所述會話描述的部件;以及 在所述通信會話期間,用來利用參加所述通信會話的其他用戶的終端的 媒體特性,根據(jù)所述代碼轉(zhuǎn)換會話,對來自一個用戶的終端的媒體流進行代 碼轉(zhuǎn)換,并且根據(jù)所述會話描述,將代碼轉(zhuǎn)換的媒體流發(fā)送給所述其他用戶 的部件。
21. —種用來建立在具有非兼容媒體特性的終端之間的、具有會話描述 的多用戶通信會話的系統(tǒng),該系統(tǒng)包括網(wǎng)絡(luò)元件,用來邀請具有非兼容々某體特性的終端的用戶參加所述通信會話;代碼轉(zhuǎn)換服務(wù)器,用來設(shè)置代碼轉(zhuǎn)換會話,使之能夠根據(jù)關(guān)于接受了邀 請的用戶的終端的信息,進行所述終端的非兼容媒體特性之間的代碼轉(zhuǎn)換,所述信息包含所述用戶的終端的々某體特性; 其中所述代碼轉(zhuǎn)換服務(wù)器根據(jù)所述代碼轉(zhuǎn)換會話,建立所述會話描述;以及 在所述通信會話期間,所述代碼轉(zhuǎn)換服務(wù)器利用參加所述通信會話的其 他用戶的終端的媒體特性,根據(jù)所述代碼轉(zhuǎn)換會話,對來自一個用戶的終端 的媒體流進行代碼轉(zhuǎn)換,并且根據(jù)所述會話描述,將代碼轉(zhuǎn)換的媒體流發(fā)送 給所述其他用戶。
22. 如權(quán)利要求21所述的系統(tǒng),其中所述網(wǎng)絡(luò)元件為中心網(wǎng)絡(luò)元件。
23. 如權(quán)利要求22所述的系統(tǒng),其中所述中心網(wǎng)絡(luò)元件管理媒體流以及 通信會話流動。
24. 如權(quán)利要求22所述的系統(tǒng),其中所述中心網(wǎng)絡(luò)元件從第一用戶接收 邀請請求。
25. 如權(quán)利要求24所述的系統(tǒng),其中所述會話描述包括第一用戶所支持 的至少一個媒體特性。
26. 如權(quán)利要求25所述的系統(tǒng),其中所支持的媒體特性為特定編解碼器。
27. 如權(quán)利要求22所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器從所述中心網(wǎng) 絡(luò)元件接收設(shè)置所述代碼轉(zhuǎn)換會話的請求。
28. 如權(quán)利要求27所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器進一步建立代 碼轉(zhuǎn)換資源以及經(jīng)過所述代碼轉(zhuǎn)換服務(wù)器的媒體流流動。
29. 如權(quán)利要求28所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器進一步提供代 碼轉(zhuǎn)換會話信息。
30. 如權(quán)利要求29所述的系統(tǒng),其中所述代碼轉(zhuǎn)換會話信息包含以下元 素中的至少一個元素會話標(biāo)識、所述代碼轉(zhuǎn)換服務(wù)器支持代碼轉(zhuǎn)換的格式 與編解碼器的列表、以及允許媒體流流經(jīng)所述代碼轉(zhuǎn)換服務(wù)器的IP地址與端 口的列表。
31. 如權(quán)利要求30所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器進一步利用關(guān) 于接受了邀請的用戶提供的關(guān)于該接受了邀請的用戶的終端的信息,更新所 述代碼轉(zhuǎn)換會話信息。
32. 如權(quán)利要求31所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器進一步根據(jù)接 受了邀請的用戶提供的信息,更新所述代碼轉(zhuǎn)換資源與媒體流流動。
33. 如權(quán)利要求32所述的系統(tǒng),其中在所述代碼轉(zhuǎn)換會話期間,所述代 碼轉(zhuǎn)換服務(wù)器確定要執(zhí)行的代碼轉(zhuǎn)換操作以及代碼轉(zhuǎn)換的媒體流要送往的端 口和IP地址。
34. 如權(quán)利要求32所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器根據(jù)所述代碼 轉(zhuǎn)換會話信息,更新所述會話描述。
35. 如權(quán)利要求21所述的系統(tǒng),其中所述網(wǎng)絡(luò)元件包括每個參加所述多 用戶通信會話的用戶的本地網(wǎng)絡(luò)元件。
36. 如權(quán)利要求35所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器包括多個代碼 轉(zhuǎn)換服務(wù)器,其中每個代碼轉(zhuǎn)換服務(wù)器連接到參加所述通信會話的相關(guān)用戶 的相應(yīng)本地網(wǎng)絡(luò)元件。
37. 如權(quán)利要求36所述的系統(tǒng),其中所述每個參加通信會話的用戶的本 地網(wǎng)絡(luò)元件管理與其相關(guān)的代碼轉(zhuǎn)換服務(wù)器。
38. 如權(quán)利要求37所述的系統(tǒng),包括管理講話許可權(quán)與i某體流動的中 心網(wǎng)絡(luò)元件。
39. 如權(quán)利要求35所述的系統(tǒng),包括用來將來自第一用戶的邀請請求 提供給該第一用戶的本地網(wǎng)絡(luò)元件的部件。
40. 如權(quán)利要求39所述的系統(tǒng),其中所述會話描述包括第一用戶支持的 至少一個媒體特性。
41. 如權(quán)利要求40所述的系統(tǒng),其中所支持的々某體特性為特定編解碼器。
42. 如權(quán)利要求35所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器從第一用戶的 本地網(wǎng)絡(luò)元件接收設(shè)置所述代碼轉(zhuǎn)換會話的請求。
43. 如權(quán)利要求42所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器進一步建立代 碼轉(zhuǎn)換資源以及經(jīng)過所述代碼轉(zhuǎn)換服務(wù)器的々某體流流動。
44. 如權(quán)利要求43所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器進一步提供代 碼轉(zhuǎn)換會話信息。
45. 如權(quán)利要求44所述的系統(tǒng),其中所述代碼轉(zhuǎn)換會話信息包含以下元 素中的至少一個元素會話標(biāo)識、所述代碼轉(zhuǎn)換服務(wù)器支持代碼轉(zhuǎn)換的格式 與編解碼器的列表、以及允許媒體流流經(jīng)所述代碼轉(zhuǎn)換服務(wù)器的IP地址與端 口的列表。
46. 如權(quán)利要求45所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器進一步利用接受了邀請的用戶提供的關(guān)于所述接受了邀請的用戶的終端的信息,更新所述 代碼轉(zhuǎn)換會話信息。
47. 如權(quán)利要求46所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器進一步根據(jù)接 受了邀請的用戶提供的信息,更新所述代碼轉(zhuǎn)換資源以及々某體流流動。
48. 如權(quán)利要求47所述的系統(tǒng),其中在所述代碼轉(zhuǎn)換會話期間,所述代 碼轉(zhuǎn)換服務(wù)器確定要執(zhí)行的代碼轉(zhuǎn)換操作以及代碼轉(zhuǎn)換的媒體流要送往的端 口和IPi也址。
49. 如權(quán)利要求24所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器截獲從第一用 戶到所述中心網(wǎng)絡(luò)元件的邀請請求。
50. 如權(quán)利要求49所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器進一步作為在 所述中心網(wǎng)絡(luò)元件與第 一用戶之間的通信路徑中的代理服務(wù)器。
51. 如權(quán)利要求50所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器獨立于所述中 心網(wǎng)絡(luò)元件以及第 一用戶的本地網(wǎng)絡(luò)元件。
52. 如權(quán)利要求49所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器進一步建立代 碼轉(zhuǎn)換資源以及流經(jīng)所述代碼轉(zhuǎn)換服務(wù)器的媒體流流動。
53. 如權(quán)利要求52所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器進一步提供代 碼轉(zhuǎn)換會話信息。
54. 如權(quán)利要求53所述的系統(tǒng),其中所述代碼轉(zhuǎn)換會話信息包含以下元 素中的至少一個元素會話標(biāo)識、所述代碼轉(zhuǎn)換服務(wù)器支持代碼轉(zhuǎn)換的格式 與編解碼器的列表、以及允許々某體流流經(jīng)所述代碼轉(zhuǎn)換服務(wù)器的IP地址與端 口的列表。
55. 如權(quán)利要求54所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器進一步利用接 受了參加所述通信會話的邀請的用戶提供的信息,更新所述代碼轉(zhuǎn)換會話信
56. 如權(quán)利要求55所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器進一步根據(jù)接受了參加所述通信會話的邀請的用戶提供的信息,更新所述代碼轉(zhuǎn)換資源與媒體流流動。
57. 如權(quán)利要求56所述的系統(tǒng),其中在所述代碼轉(zhuǎn)換會話期間,所述代碼轉(zhuǎn)換服務(wù)器確定要執(zhí)行的代碼轉(zhuǎn)換操作以及代碼轉(zhuǎn)換的媒體流要送往的端口和IP地址。
58. 如權(quán)利要求49所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器使用IP交換機來截獲來自所述中心網(wǎng)絡(luò)元件的消息。
59. 如權(quán)利要求28所述的系統(tǒng),其中所述媒體流包括講話猝發(fā)分組與媒體分組。
60. 如權(quán)利要求59所述的系統(tǒng),其中所述講話摔發(fā)分組包括在所述用戶與網(wǎng)絡(luò)元件之間交換的講話請求與響應(yīng)。
61. 如權(quán)利要求59所述的系統(tǒng),包括用來向所述代碼轉(zhuǎn)換服務(wù)器提供所有媒體流的部件。
62. 如權(quán)利要求61所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器對所述媒體分組進行代碼轉(zhuǎn)換,并且將所述講話猝發(fā)分組轉(zhuǎn)發(fā)給所述網(wǎng)絡(luò)元件。
63. 如權(quán)利要求61所述的系統(tǒng),包括用來向所述中心網(wǎng)絡(luò)元件提供所有媒體流的部件。
64. 如權(quán)利要求63所述的系統(tǒng),包括用來僅將媒體分組轉(zhuǎn)發(fā)給所述代碼轉(zhuǎn)換服務(wù)器進行代碼轉(zhuǎn)換的部件。
65. 如權(quán)利要求62所述的系統(tǒng),其中所述中心網(wǎng)絡(luò)元件通知所述代碼轉(zhuǎn)換服務(wù)器哪個參加的用戶具有講話許可權(quán)。
66. 如權(quán)利要求62所述的系統(tǒng),其中所述代碼轉(zhuǎn)換服務(wù)器通過查看所述講話猝發(fā)分組,來導(dǎo)出哪個參加的用戶具有講話許可權(quán)。
全文摘要
一種用來建立在具有非兼容媒體特性的終端之間的、具有會話描述的多用戶通信會話的方法與系統(tǒng),其中邀請具有非兼容媒體特性的終端的用戶參加通信會話。設(shè)置代碼轉(zhuǎn)換會話,使之能夠根據(jù)關(guān)于接受了邀請的用戶的終端的信息,進行終端的非兼容媒體特性之間的代碼轉(zhuǎn)換,信息包含該用戶的終端的媒體特性。根據(jù)代碼轉(zhuǎn)換會話,建立會話描述;以及在通信會話期間,利用參加通信會話的其他用戶的終端的媒體特性,根據(jù)代碼轉(zhuǎn)換會話,對來自一個用戶的終端的媒體流進行代碼轉(zhuǎn)換,并且根據(jù)會話描述,將代碼轉(zhuǎn)換的媒體流發(fā)送給其他用戶。
文檔編號H04W88/18GK101390415SQ200680053567
公開日2009年3月18日 申請日期2006年12月27日 優(yōu)先權(quán)日2005年12月28日
發(fā)明者斯蒂法妮·庫隆比 申請人:梵提克斯公司