專利名稱：群呼叫能力查詢的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及用于處理電信系統(tǒng)中的多媒體會(huì)議呼叫的系統(tǒng)和方法。
背景技術(shù)：
電信網(wǎng)絡(luò)中的多媒體會(huì)議已經(jīng)是多個(gè)標(biāo)準(zhǔn)化團(tuán)體的標(biāo)準(zhǔn)化的目
標(biāo)。對(duì)于基于分組的網(wǎng)絡(luò)，ITU-T已經(jīng)在保護(hù)推薦H. 323中提出多i某 體通信的多個(gè)推薦。H. 323涉及多個(gè)其它推薦，例如描述呼叫信令、 々某體(音頻和視頻)、流分組、媒體流同步和控制消息格式的H. 225. 0 協(xié)議，以及描述補(bǔ)充服務(wù)的推薦H. 450。另一個(gè)信令協(xié)議是SIP(會(huì)話 初始協(xié)議)，它由IETF在規(guī)范RFC 3261中規(guī)定。RFC 3261規(guī)定了多 個(gè)SIP消息，并且這些消息攜帶了 RFC 2327中規(guī)定的會(huì)話描述協(xié)議 (SDP)。
當(dāng)前，例如3GPP和3GPP2(第三代合作伙伴項(xiàng)目)等電信團(tuán)體中的 首創(chuàng)性是規(guī)定了電信服務(wù)的下一代分組交換核心網(wǎng)絡(luò)。在3GPP中，核 心網(wǎng)絡(luò)域稱作IMS (IP多々某體子系統(tǒng))。3GPP當(dāng)前正擬定包括IMS中的 多個(gè)補(bǔ)充服務(wù)的支持的要求(例如3GPP TS 22.173)。補(bǔ)充服務(wù)的一個(gè) 示例是多i某體會(huì)議(或群呼叫)，其中可涉及多個(gè)多々某體終端，并且各 終端可支持不同的纟某體類型。i某體類型通常按照MIME標(biāo)準(zhǔn)(RFC 2046) 來規(guī)定。
另外，開放移動(dòng)聯(lián)盟(OMA)已經(jīng)定義了通過蜂窩的PoC按4定通話 (PoC)的標(biāo)準(zhǔn)。參見例如通過蜂窩的按《睫通話(PoC)體系結(jié)構(gòu)，草案版 本2. 0 - 2007年3月，開》文移動(dòng)聯(lián)盟，0MA-AD—PoC-V2-0-20070326-D， 通過引用將其結(jié)合到本文中。0MA PoC規(guī)范集利用了來自IETF、 3GPP
5和3GPP2的多個(gè)現(xiàn)有規(guī)范，包括3GPP IP多^某體子系統(tǒng)(IMS)和3GPP2 多i某體域(固D)以使能包括多方會(huì)議的移動(dòng)裝置之間的IP連通性和基 于IP的通信的能力。
在電信系統(tǒng)(例如其中通過使用SIP信令來建立和控制呼叫的IMS) 中，確定遠(yuǎn)程終端的能力的方式是4吏用在IETF RFC 3261中描述的稱 作OPTIONS的SIP方法。這種方法允許用戶終端查詢另一個(gè)用戶終端 或者代理服務(wù)器有關(guān)于其能力。這允許客戶端發(fā)現(xiàn)與所支持方法、內(nèi) 容類型、擴(kuò)展、編解碼器等有關(guān)的信息，而無需"振鈴"另 一方。OPTIONS 響應(yīng)是所謂的200 OK消息，其中具有描述遠(yuǎn)程端的i某體支持的所附 SDP。 200 OK響應(yīng)還可包括特征標(biāo)簽，表明OPTIONS的發(fā)送方得知可 能對(duì)其有用的其它能力。

發(fā)明內(nèi)容
SIP中的當(dāng)前OPTIONS方法的一個(gè)限制在于，對(duì)于各OPTIONS請(qǐng) 求僅可存在一個(gè)OPTIONS響應(yīng)。在多i某體會(huì)議中，這成為問題，因?yàn)?用戶希望知道所有會(huì)議參與者通常支持什么。涉及例如5個(gè)參與者的 會(huì)議呼叫不能對(duì)一個(gè)參與者所發(fā)送的單個(gè)OPTIONS請(qǐng)求返回5個(gè) OPTIONS響應(yīng)。
在本發(fā)明中，上述問題通過實(shí)現(xiàn)以下方法來解決使用位于所涉 及用戶終端(客戶端)之間的服務(wù)器，服務(wù)器收集參與者的用戶終端的 每個(gè)的所支持能力(例如媒體類型、補(bǔ)充服務(wù)等)，并且匯總所支持能 力的7>共集合(common set)，并且在單個(gè)響應(yīng)消息(例如200 OK響應(yīng)) 中返回那些能力，單個(gè)響應(yīng)消息然后表示對(duì)會(huì)議的支持。
該解決方案是發(fā)送一個(gè)具有群呼叫上下文的服務(wù)查詢消息(例如 OPTIONS請(qǐng)求)，并且使消息端接于服務(wù)器(例如群呼叫服務(wù)器)中。所 述服務(wù)器向各參與者發(fā)送一個(gè)服務(wù)查詢消息(例如OPTIONS請(qǐng)求)，并 且等待其響應(yīng)(例如在200 OK響應(yīng)中)。此后，服務(wù)器對(duì)于從各參與者 終端所接收的共同支持的能力進(jìn)行分析。服務(wù)器可以可選地分析由于非預(yù)訂能力而可能禁止某種支持(雖然終端對(duì)它支持)的任何系統(tǒng)策 略、群策略和訂戶策略。在分析所有這些參數(shù)之后，服務(wù)器形成集合
200 0K響應(yīng)，其中包括為與所支持能力有關(guān)的信息的SDP描述。如果 75°/。的參與者支持視頻，則服務(wù)器可作為一種策略來判定將例如視頻作 為一種可能性包含在呼叫中。
服務(wù)詢問消息(例如OPTIONS請(qǐng)求)可在正進(jìn)行的會(huì)議呼叫期間發(fā) 送，或者沒有涉及任何正進(jìn)行呼叫。
這種解決方案的一個(gè)優(yōu)點(diǎn)在于，會(huì)議呼叫可通過預(yù)先知道其它用 戶終端可支持什么能力來建立。因此不需要多次反復(fù)試驗(yàn)呼叫建立。
另 一個(gè)優(yōu)點(diǎn)在于，會(huì)議呼叫中每個(gè)所涉及終端可用的能力可通過 用戶友好方式在終端上向用戶呈現(xiàn)。例如，具有顯示器的移動(dòng)電話可 呈現(xiàn)表示所涉及的各終端的能力的圖標(biāo)。這使會(huì)議服務(wù)對(duì)用戶更有吸 引力，并且最后將鼓勵(lì)用戶在網(wǎng)絡(luò)中產(chǎn)生更多業(yè)務(wù)，這，于于網(wǎng)絡(luò)運(yùn)營(yíng) 商是有益的。
又一個(gè)優(yōu)點(diǎn)在于，當(dāng)新的共享多々某體月1務(wù)進(jìn)入市場(chǎng)時(shí)，可采用它 們來擴(kuò)展所述方法。
因此，本發(fā)明的目標(biāo)是簡(jiǎn)化多i某體會(huì)議呼叫中的多々某體終端之間 的通信。
現(xiàn)在通過優(yōu)選實(shí)施例并參照附圖更詳細(xì)地描述本發(fā)明。


圖1是示出根據(jù)本發(fā)明的能夠訪問群呼叫服務(wù)器的終端組的框圖。
圖2是示出根據(jù)本發(fā)明的方法來確定多^某體終端所支持的能力的 步驟的流程圖。
圖3是示出分為多個(gè)子服務(wù)器的服務(wù)器的框圖。
具體實(shí)施例方式
7圖1描述了能夠訪問服務(wù)器(群呼叫服務(wù)器100)的一組110終端
111- 114。群呼叫服務(wù)器IOO適合接收來自組110中的終端111的SIP OPTIONS請(qǐng)求121。服務(wù)器100還適合向組110中的多個(gè)其它終端
112- 114廣播SIP option請(qǐng)求131、 141、 151。
群呼叫服務(wù)器100包括存儲(chǔ)器區(qū)域(高速緩存)105,它適合存儲(chǔ)組 110中的所涉及終端112-114的能力。
圖1還示出組110中的終端111-114與群呼叫服務(wù)器100之間的 信息流程
1) 終端l 111在正進(jìn)行的SIP會(huì)議中發(fā)送SIP OPTIONS請(qǐng)求121。 SIP OPTIONS請(qǐng)求121針對(duì)于群呼叫服務(wù)器100。
2) 群呼叫服務(wù)器100向終端2 112發(fā)送SIP OPTIONS請(qǐng)求l31。
3) 群呼叫服務(wù)器100向終端3 113發(fā)送SIP OPTIONS請(qǐng)求l41。
4) 群呼叫服務(wù)器100向終端4 114發(fā)送SIP OPTIONS請(qǐng)求l51。
5) 群呼叫服務(wù)器100接收來自終端2 112的(例如)指明它支持m= 音頻、見頻、m-消息傳遞的SIP 200 OK響應(yīng)132。
6) 群呼叫服務(wù)器100接收來自終端3 113的(例如)指明它支持m= 音頻、m—見頻的SIP 200 OK響應(yīng)142。
7) 群呼叫服務(wù)器100接收來自終端4 114的(例如)指明它支持m= 音頻、見頻、m-消息傳遞的SIP 200 OK響應(yīng)152。
8) 群呼叫服務(wù)器100檢查可能限制(例如)終端1111使用視頻(盡 管所有參與者裝置都支持它)的任何系統(tǒng)、群或訂戶策略。然后，群服 務(wù)器100創(chuàng)建對(duì)終端1 111的具有能力的公共集合的公共SIP 200 OK 響應(yīng)122。在上述示例中，SIP 200 OK 122包含具有m-音頻和見頻 的SDP。這是因?yàn)榻K端3 113不支持消息傳遞，盡管終端2 (U2)和終 端4 114支持。
9) 當(dāng)終端1 111接收到200 OK響應(yīng)122時(shí)，它分析所附的SDP。 如果終端1 111具有顯示器，則諸如'添加^f見頻，的圖標(biāo)(例如)在顯 示器上作為軟按鈕而加亮顯示。按下那個(gè)按鈕就會(huì)引起對(duì)終端2-4112-114的視頻流。
通過使用這種方法，存在一種使終端1 lll學(xué)習(xí)會(huì)議呼叫中所涉
及的所有其它終端112-114的能力的方式。
為了節(jié)省信令，群呼叫服務(wù)器100能夠可選地把來自各終端 112-114的響應(yīng)132、 142、 152存儲(chǔ)在存儲(chǔ)器區(qū)域105中。當(dāng)另一個(gè) 終端發(fā)送SIP OPTION請(qǐng)求時(shí)，即，如果圖1的配置中的終端2 112發(fā) 送SIP OPTIONS請(qǐng)求171，則群呼叫服務(wù)器100僅向終端1 111發(fā)送SIP OPTIONS請(qǐng)求172，因?yàn)閬碜越K端3 113的SIP 200 OK響應(yīng)142和終 端4 114的SIP 200 OK響應(yīng)152的內(nèi)容在向終端2 112發(fā)送SIP 200 OK響應(yīng)173之前是服務(wù)器100已經(jīng)知道的。
圖2是描述從群呼叫服務(wù)器100看到的、本發(fā)明的要求保護(hù)的方 法的流程圖。在步驟201,群呼叫服務(wù)器IOO接收來自組110中的終 端111的第一服務(wù)詢問消息121 (例如OPTIONS請(qǐng)求)。在步驟202,服 務(wù)器100向組110中的其它終端112-114中的至少一個(gè)廣播第二月良務(wù) 詢問消息(OPTIONS請(qǐng)求)131、 141、 151。在步驟203，服務(wù)器100接 收來自^皮詢問終端112-114的各個(gè)的第一服務(wù)響應(yīng)消息(例如200 OK 消息)132、 142、 152?？蛇x地，服務(wù)器IOO把來自終端112-114的所 有所接收服務(wù)響應(yīng)消息132、 142、 152存儲(chǔ)在存儲(chǔ)器區(qū)域105中。在 步驟205，服務(wù)器100分析所接收服務(wù)響應(yīng)消息132、 142、 152中的 內(nèi)容，并且在步驟206確定服務(wù)的公共集合。然后在步驟207，這個(gè) 服務(wù)的公共集合在服務(wù)響應(yīng)消息(200 OK消息)中發(fā)送給終端111。
圖3示出根據(jù)例如3gpp多4某體電話或OMA PoC等應(yīng)用分為若干服 務(wù)器的群呼叫服務(wù)器300。圖3包括自主服務(wù)器(ad hoc server) 310 和多個(gè)子服務(wù)器311-313。自主服務(wù)器310是從終端111可訪問的， 并且子服務(wù)器311-313是分別從終端112-114可訪問的。
圖3是適用于(例如),tel(多々某體電話)自主群呼叫或1-1 PoC會(huì) 話和自主PoC會(huì)話的多服務(wù)器配置的示例。
服務(wù)于終端112-114的服務(wù)器311-313可根據(jù)被服務(wù)用戶的預(yù)訂
9和服務(wù)提供商的本地策略來修改所接收的服務(wù)響應(yīng)消息(2 0 0 OK) 351-353的內(nèi)容。
自主服務(wù)器310匯總來自子服務(wù)器311-313的所接收響應(yīng) 322-324，并且可在向終端1 111發(fā)送OPTIONS響應(yīng)321之前應(yīng)用群策 略，如預(yù)訂選項(xiàng)和服務(wù)提供商的本地策略。
在所述實(shí)施例中，本發(fā)明基本上適用于蜂窩上PoC按鍵通話。本 領(lǐng)域的技術(shù)人員將發(fā)明的概念應(yīng)用于多個(gè)其它網(wǎng)絡(luò)場(chǎng)景，例如3GPP多 々某體電話、固tel自主群等。
下面^^人RFC 3261摘錄的OPTION方法的詳細(xì)描述。
SIP方法OPTIONS允許UA (用戶代理)向另 一個(gè)UA或代理服務(wù)器查 詢其能力。這允許客戶端發(fā)現(xiàn)與所支持方法、內(nèi)容類型、擴(kuò)展、編解 碼器等有關(guān)的信息，而無需使另一方"振鈴"。例如，在客戶端將請(qǐng) 求(Require)報(bào)頭字段插入列示它不確定目標(biāo)UAS (用戶代理服務(wù)器)是 否支持的選項(xiàng)的INVITE之前，客戶端可采用OPTIONS查詢目標(biāo)UAS以 便查看這是否在被支持(Supported)報(bào)頭字段中返回。所有UA必須支 持OPTIONS方法。
OPTIONS請(qǐng)求的目標(biāo)通過Request-URI來識(shí)別，其可識(shí)別另一個(gè) UA或SIP服務(wù)器。如果OPTIONS針對(duì)的是代理服務(wù)器，則設(shè)置 Request-URI而沒有用戶部分，這與對(duì)于REGISTER請(qǐng)求設(shè)置 Request-URI的方式相似。
備選地，接收具有Max-Forwards才良頭字段值為0的OPTIONS請(qǐng)求 的服務(wù)器響應(yīng)該請(qǐng)求，而不管Request-URI。
這種行為是與HTTP/1. 1 —樣的。通過發(fā)送具有遞增Max-Forwards 值的一系列OPTIONS請(qǐng)求，這種行為可用作"跟蹤路由"功能性以便 檢查各跳服務(wù)器的能力。
如一般UA行為情況，如果OPTIONS沒有產(chǎn)生響應(yīng)，則事務(wù)層可返 回超時(shí)誤差。這可指明目標(biāo)不可達(dá)、因而不可用。
OPTIONS請(qǐng)求可作為已建立對(duì)話的一部分而發(fā)送，以便向?qū)Φ润w查詢稍后可用于對(duì)話的能力。
OPTIONS請(qǐng)求被使用如RFC 3261第8.1. 1小節(jié)中論述的SIP請(qǐng)求 的標(biāo)準(zhǔn)規(guī)則來構(gòu)成。
聯(lián)系(Contact)報(bào)頭字段可存在于OPTIONS中。
應(yīng)當(dāng)包含接受(Acceptance)報(bào)頭字段，以便指明UAC(用戶代理客 戶端)希望在響應(yīng)中接收的消息主體的類型。這通常設(shè)置成用于描述 UA的媒體能力的格式，例如SDP(應(yīng)用/sdp)。
對(duì)OPTIONS請(qǐng)求的響應(yīng)^^底定為至原始請(qǐng)求中的Request-URI的 范圍。但是，僅當(dāng)OPTIONS作為已建立對(duì)話的一部分發(fā)送時(shí)，才保證 將來的請(qǐng)求才由生成OPTIONS的服務(wù)器接收。
示例OPTIONS請(qǐng)求 OPTIONS sip:carol@chicago.com SIP/2.0
Via: SIP/2.O/UDP pc33 . atlanta. com,. branch-z9hG4bKhjhs8ass877 Max-Foi:wai:cls: 70
To: <sip:carol@chicago.com>
From: Alice <sip:alice@atlanta.com>'.tag-1928301774 Call-ID: a84b化76e66710 CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33 atlanta com> Accept: application/sdp Content—Length: 0
對(duì)OPTIONS的響應(yīng)使用如RFC 3261第8. 2. 6小節(jié)中論述的SIP響 應(yīng)的標(biāo)準(zhǔn)規(guī)則來構(gòu)成。所選的響應(yīng)代碼必須與請(qǐng)求是INVITE時(shí)所選的 相同。也就是說，如果UAS準(zhǔn)備接受呼叫，則返回200 (OK),如果UAS 忙，則返回486 (在這里為忙)，等。這允許OPTIONS請(qǐng)求被用于確定UAS的基本狀態(tài)，它可以是關(guān)于UAS是否將接受INVITE請(qǐng)求的指示。
在對(duì)話中所4妄收的OPTIONS "^青求生成200 (0K)響應(yīng)，該響應(yīng)與在 對(duì)話外部所構(gòu)成的響應(yīng)相同，并且對(duì)于對(duì)話沒有任何影響。
OPTIONS的這種使用因OPTIONS和INVITE請(qǐng)求的代理處理的差異 而具有限制。雖然分叉(forked) INVITE可引起返回多個(gè)200 (OK)響應(yīng)， 4旦是分叉OPTIONS ^5l引起單個(gè)200 (0K)響應(yīng)，因?yàn)樗纱硎褂梅?INVITE處理來對(duì)待。關(guān)于標(biāo)準(zhǔn)細(xì)節(jié)，參見RFC 3261第16.7小節(jié)。
如果對(duì)OPTIONS的響應(yīng)由代理服務(wù)器生成，則代理返回200 (OK)， 列示出服務(wù)器的能力。
響應(yīng)不包含消息主體。
允許(Allow)、接受(Accept)、接受-編碼(Accept-Encoding)、接 受-語言(Accept-Language)和被支持(Supported)才艮頭字段應(yīng)當(dāng)存在 于對(duì)OPTIONS的200 (OK)響應(yīng)中。如果響應(yīng)由代理生成，則當(dāng)允許才良 頭字段不明確時(shí)應(yīng)當(dāng)將其省略，因?yàn)榇硎欠椒ú豢芍摰摹Ｂ?lián)系報(bào) 頭字段可存在于200 (0K)中，并且具有與3xx響應(yīng)中相同的語義。也 就是說，它們可顯示一組到達(dá)用戶的備選名稱和方法?？纱嬖诟婢?(Warning)才艮頭字段。
可發(fā)送消息主體，其類型由OPTIONS請(qǐng)求中的接受報(bào)頭字段來確 定(如果接受報(bào)頭字段不存在，則應(yīng)用/sdp為缺省)。如果類型中包括 能夠描述^某體能力的類型，則UAS為該目的應(yīng)當(dāng)將主體包含在響應(yīng)中。 在RFC 3264中描述了關(guān)于在應(yīng)用/sdp的情況下構(gòu)成這種主體的細(xì)節(jié)。
由UAS生成的示例OPTIONS響應(yīng)(與上述請(qǐng)求對(duì)應(yīng))SIP/2.0 200 OK
Via:SIP/2. 0/UDP pc33 . atlanta .com,'branch-z9hG4bKhjhs8ass877 r:eceiveci=a92.0.2.4
To: <sip:carol@chicago*cora>,'tag=93810874
From: Alice <sip:alice@atlanta.com"tag-1928301774
Call-ID: a8化4c76e66710
CSeq: 63104 OPTIONS
Contact i <sip.. carol@chicago com>
Contact: <mailto: carol( chicago com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Accept: application/sdp
Accept-Encodingt gzip
Accept-Iianguage: en
Supported: foo
Content-Type: application/sdp
Content-Iiengthr 274
(SDP未示出)
權(quán)利要求
1.一種在電信網(wǎng)絡(luò)中確定由構(gòu)成組(110)的多個(gè)多媒體終端(111-114)所支持的多媒體能力的方法，其特征在于以下步驟-接收(201)來自第一多媒體終端(111)的第一服務(wù)詢問消息(121)；-向所述組(110)中的其它多媒體終端(112-114)中的至少一個(gè)發(fā)送(202)第二服務(wù)詢問消息(131，141，151)；-從所述其它多媒體終端(112-114)接收(203)作為對(duì)所述第二服務(wù)詢問消息(131，141，151)的響應(yīng)的第一服務(wù)響應(yīng)消息(132，142，152)；-分析(205)所述第一服務(wù)響應(yīng)消息(132，142，152)中的所接收的能力；-確定(206)能力的公共集合；-向所述第一多媒體終端(111)發(fā)送作為所述第一服務(wù)詢問消息(121)的響應(yīng)的第二服務(wù)響應(yīng)消息(122)，所述第二服務(wù)響應(yīng)消息(122)包括所述能力的公共集合的。
2. 如權(quán)利要求l所述的方法，其中，確定所述能力的公共集合的 所述步驟還包括應(yīng)用策略的步驟。
3. 如權(quán)利要求2所述的方法，其中，所述策略是以下任一個(gè)或者 其組合畫系統(tǒng)策略； -群策略； -訂戶策略。
4. 如權(quán)利要求1所述的方法，還包括存儲(chǔ)(204)所接收的能力的 步驟。
5. 如權(quán)利要求4所述的方法，還包括以下步驟-接收來自第二多媒體終端(112)的第三服務(wù)詢問消息(171);-向所述第 一多々某體終端(111)發(fā)送第四服務(wù)詢問消息(171);-從所述其它多^ 某體終端(lll)接收作為對(duì)所述第三服務(wù)詢問消 息(171)的響應(yīng)的第三服務(wù)響應(yīng)消息(172);-連同所存儲(chǔ)的能力分析所述第三服務(wù)響應(yīng)消息(172)中的所接 收的能力；畫確定能力的第二公共集合；-向所述第二多媒體終端(112)發(fā)送作為所述第四服務(wù)詢問消息 (121)的響應(yīng)的第四服務(wù)響應(yīng)消息(173)，所述第四服務(wù)響應(yīng)消息(17 3) 包括所述能力的第二公共集合的。
6. 如權(quán)利要求3或5所述的方法，其中，所述服務(wù)詢問消息(121, 131， 171)是SIP OPTIONS請(qǐng)求，并且服務(wù)響應(yīng)消息(122, 132， 172) 是SIP 200 0K響應(yīng)。
7. 如以上權(quán)利要求中的任一項(xiàng)所述的方法，其中，所述組(110) 中的所述多i某體終端(111-114)參與多i某體會(huì)議呼叫。
8. —種在電信網(wǎng)絡(luò)中/人包括多個(gè)多々某體終端(111-114)的組(IIO) 可訪問的多^某體應(yīng)用服務(wù)器(100)，其中，所述服務(wù)器(100)的特征在 于它適合于-響應(yīng)從第一多i某體終端(lll)所接收的服務(wù)詢問消息(121)，從 所述組(110)中的至少一個(gè)第二多i某體終端(112-114)收集能力； -分析所收集的能力，并且確定能力的公共集合。 -向所述第一多媒體終端(112-114)返回包括所述能力的公共集 合的服務(wù)響應(yīng)消息(122)。
9. 如權(quán)利要求8所述的多々某體應(yīng)用服務(wù)器(100)，還包括適合 存儲(chǔ)所收集的能力的存儲(chǔ)器區(qū)域(105)。
10. 如權(quán)利要求9所述的多4某體應(yīng)用服務(wù)器(100)，還適合當(dāng)確定 所述能力的公共集合時(shí)應(yīng)用策略。
11. 如權(quán)利要求10所述的多i某體應(yīng)用服務(wù)器(100),還適合連同 所述存儲(chǔ)器區(qū)域(105)中已經(jīng)存儲(chǔ)的能力分析所述所收集的能力。
12. 如權(quán)利要求8至12中的任一項(xiàng)所述的多媒體應(yīng)用服務(wù)器 (310-313),還適合于可連接到至少一個(gè)其它多媒體應(yīng)用服務(wù)器 (310-313)。
13. —種包括相互連接的如權(quán)利要求12所述的多々某體應(yīng)用服務(wù)器 的多個(gè)多媒體應(yīng)用服務(wù)器(310- 313)的系統(tǒng)(3 0 0)。
14. 如權(quán)利要求13所述的系統(tǒng)(300)，其中，所述服務(wù)器(310-313) 在取決于應(yīng)用的配置中相互連接。
15. 如權(quán)利要求14所述的系統(tǒng)(300),其中， 一個(gè)服務(wù)器是自主 服務(wù)器(310),而其它服務(wù)器是連接到所述自主服務(wù)器(310)的子服務(wù) 器(311-313)，并且所述自主服務(wù)器(310)還適合匯總從所述子服務(wù)器 (311-313)所接收的服務(wù)響應(yīng)消息(322-324)。
全文摘要
本發(fā)明涉及用于處理電信系統(tǒng)中的多媒體會(huì)議呼叫的系統(tǒng)和方法。為了使組(110)中的第一終端(111)確定組(110)中的至少其它終端(112-114)的能力，可向其它終端(112-114)發(fā)送查詢消息。當(dāng)使用SIP(會(huì)話初始協(xié)議)時(shí)，查詢通過發(fā)送OPTIONS消息的方法來執(zhí)行。這種方法的限制在于，組中的各終端(111)需要向組中的所有其它終端(112-114)發(fā)送查詢，以便確定彼此的能力。本發(fā)明包括公共服務(wù)器(100)，它適合收集與組中的終端(112-114)的能力有關(guān)的信息，并且確定發(fā)送給第一終端(111)的能力的公共集合。
文檔編號(hào)H04L29/06GK101682617SQ200880015462
公開日2010年3月24日 申請(qǐng)日期2008年4月21日 優(yōu)先權(quán)日2007年5月11日
發(fā)明者J·霍爾姆, M·斯蒂爾 申請(qǐng)人:艾利森電話股份有限公司