专利名称：群呼叫能力查询的制作方法
技术领域：
本发明涉及用于处理电信系统中的多媒体会议呼叫的系统和方法。
背景技术：
电信网络中的多媒体会议已经是多个标准化团体的标准化的目
标。对于基于分组的网络，ITU-T已经在保护推荐H. 323中提出多i某 体通信的多个推荐。H. 323涉及多个其它推荐，例如描述呼叫信令、 々某体(音频和视频)、流分组、媒体流同步和控制消息格式的H. 225. 0 协议，以及描述补充服务的推荐H. 450。另一个信令协议是SIP(会话 初始协议)，它由IETF在规范RFC 3261中规定。RFC 3261规定了多 个SIP消息，并且这些消息携带了 RFC 2327中规定的会话描述协议 (SDP)。
当前，例如3GPP和3GPP2(第三代合作伙伴项目)等电信团体中的 首创性是规定了电信服务的下一代分组交换核心网络。在3GPP中，核 心网络域称作IMS (IP多々某体子系统)。3GPP当前正拟定包括IMS中的 多个补充服务的支持的要求(例如3GPP TS 22.173)。补充服务的一个 示例是多i某体会议(或群呼叫)，其中可涉及多个多々某体终端，并且各 终端可支持不同的纟某体类型。i某体类型通常按照MIME标准(RFC 2046) 来规定。
另外，开放移动联盟(OMA)已经定义了通过蜂窝的PoC按4定通话 (PoC)的标准。参见例如通过蜂窝的按《睫通话(PoC)体系结构，草案版 本2. 0 - 2007年3月，开》文移动联盟，0MA-AD—PoC-V2-0-20070326-D， 通过引用将其结合到本文中。0MA PoC规范集利用了来自IETF、 3GPP
5和3GPP2的多个现有规范，包括3GPP IP多^某体子系统(IMS)和3GPP2 多i某体域(固D)以使能包括多方会议的移动装置之间的IP连通性和基 于IP的通信的能力。
在电信系统(例如其中通过使用SIP信令来建立和控制呼叫的IMS) 中，确定远程终端的能力的方式是4吏用在IETF RFC 3261中描述的称 作OPTIONS的SIP方法。这种方法允许用户终端查询另一个用户终端 或者代理服务器有关于其能力。这允许客户端发现与所支持方法、内 容类型、扩展、编解码器等有关的信息，而无需"振铃"另 一方。OPTIONS 响应是所谓的200 OK消息，其中具有描述远程端的i某体支持的所附 SDP。 200 OK响应还可包括特征标签，表明OPTIONS的发送方得知可 能对其有用的其它能力。
发明内容
SIP中的当前OPTIONS方法的一个限制在于，对于各OPTIONS请 求仅可存在一个OPTIONS响应。在多i某体会议中，这成为问题，因为 用户希望知道所有会议参与者通常支持什么。涉及例如5个参与者的 会议呼叫不能对一个参与者所发送的单个OPTIONS请求返回5个 OPTIONS响应。
在本发明中，上述问题通过实现以下方法来解决使用位于所涉 及用户终端(客户端)之间的服务器，服务器收集参与者的用户终端的 每个的所支持能力(例如媒体类型、补充服务等)，并且汇总所支持能 力的7>共集合(common set)，并且在单个响应消息(例如200 OK响应) 中返回那些能力，单个响应消息然后表示对会议的支持。
该解决方案是发送一个具有群呼叫上下文的服务查询消息(例如 OPTIONS请求)，并且使消息端接于服务器(例如群呼叫服务器)中。所 述服务器向各参与者发送一个服务查询消息(例如OPTIONS请求)，并 且等待其响应(例如在200 OK响应中)。此后，服务器对于从各参与者 终端所接收的共同支持的能力进行分析。服务器可以可选地分析由于非预订能力而可能禁止某种支持(虽然终端对它支持)的任何系统策 略、群策略和订户策略。在分析所有这些参数之后，服务器形成集合
200 0K响应，其中包括为与所支持能力有关的信息的SDP描述。如果 75°/。的参与者支持视频，则服务器可作为一种策略来判定将例如视频作 为一种可能性包含在呼叫中。
服务询问消息(例如OPTIONS请求)可在正进行的会议呼叫期间发 送，或者没有涉及任何正进行呼叫。
这种解决方案的一个优点在于，会议呼叫可通过预先知道其它用 户终端可支持什么能力来建立。因此不需要多次反复试验呼叫建立。
另 一个优点在于，会议呼叫中每个所涉及终端可用的能力可通过 用户友好方式在终端上向用户呈现。例如，具有显示器的移动电话可 呈现表示所涉及的各终端的能力的图标。这使会议服务对用户更有吸 引力，并且最后将鼓励用户在网络中产生更多业务，这，于于网络运营 商是有益的。
又一个优点在于，当新的共享多々某体月1务进入市场时，可采用它 们来扩展所述方法。
因此，本发明的目标是简化多i某体会议呼叫中的多々某体终端之间 的通信。
现在通过优选实施例并参照附图更详细地描述本发明。
图1是示出根据本发明的能够访问群呼叫服务器的终端组的框图。
图2是示出根据本发明的方法来确定多^某体终端所支持的能力的 步骤的流程图。
图3是示出分为多个子服务器的服务器的框图。
具体实施例方式
7图1描述了能够访问服务器(群呼叫服务器100)的一组110终端
111- 114。群呼叫服务器IOO适合接收来自组110中的终端111的SIP OPTIONS请求121。服务器100还适合向组110中的多个其它终端
112- 114广播SIP option请求131、 141、 151。
群呼叫服务器100包括存储器区域(高速緩存)105,它适合存储组 110中的所涉及终端112-114的能力。
图1还示出组110中的终端111-114与群呼叫服务器100之间的 信息流程
1) 终端l 111在正进行的SIP会议中发送SIP OPTIONS请求121。 SIP OPTIONS请求121针对于群呼叫服务器100。
2) 群呼叫服务器100向终端2 112发送SIP OPTIONS请求l31。
3) 群呼叫服务器100向终端3 113发送SIP OPTIONS请求l41。
4) 群呼叫服务器100向终端4 114发送SIP OPTIONS请求l51。
5) 群呼叫服务器100接收来自终端2 112的(例如)指明它支持m= 音频、见频、m-消息传递的SIP 200 OK响应132。
6) 群呼叫服务器100接收来自终端3 113的(例如)指明它支持m= 音频、m—见频的SIP 200 OK响应142。
7) 群呼叫服务器100接收来自终端4 114的(例如)指明它支持m= 音频、见频、m-消息传递的SIP 200 OK响应152。
8) 群呼叫服务器100检查可能限制(例如)终端1111使用视频(尽 管所有参与者装置都支持它)的任何系统、群或订户策略。然后，群服 务器100创建对终端1 111的具有能力的公共集合的公共SIP 200 OK 响应122。在上述示例中，SIP 200 OK 122包含具有m-音频和见频 的SDP。这是因为终端3 113不支持消息传递，尽管终端2 (U2)和终 端4 114支持。
9) 当终端1 111接收到200 OK响应122时，它分析所附的SDP。 如果终端1 111具有显示器，则诸如'添加^f见频，的图标(例如)在显 示器上作为软按钮而加亮显示。按下那个按钮就会引起对终端2-4112-114的视频流。
通过使用这种方法，存在一种使终端1 lll学习会议呼叫中所涉
及的所有其它终端112-114的能力的方式。
为了节省信令，群呼叫服务器100能够可选地把来自各终端 112-114的响应132、 142、 152存储在存储器区域105中。当另一个 终端发送SIP OPTION请求时，即，如果图1的配置中的终端2 112发 送SIP OPTIONS请求171，则群呼叫服务器100仅向终端1 111发送SIP OPTIONS请求172，因为来自终端3 113的SIP 200 OK响应142和终 端4 114的SIP 200 OK响应152的内容在向终端2 112发送SIP 200 OK响应173之前是服务器100已经知道的。
图2是描述从群呼叫服务器100看到的、本发明的要求保护的方 法的流程图。在步骤201,群呼叫服务器IOO接收来自组110中的终 端111的第一服务询问消息121 (例如OPTIONS请求)。在步骤202,服 务器100向组110中的其它终端112-114中的至少一个广播第二月良务 询问消息(OPTIONS请求)131、 141、 151。在步骤203，服务器100接 收来自^皮询问终端112-114的各个的第一服务响应消息(例如200 OK 消息)132、 142、 152。可选地，服务器IOO把来自终端112-114的所 有所接收服务响应消息132、 142、 152存储在存储器区域105中。在 步骤205，服务器100分析所接收服务响应消息132、 142、 152中的 内容，并且在步骤206确定服务的公共集合。然后在步骤207，这个 服务的公共集合在服务响应消息(200 OK消息)中发送给终端111。
图3示出根据例如3gpp多4某体电话或OMA PoC等应用分为若干服 务器的群呼叫服务器300。图3包括自主服务器(ad hoc server) 310 和多个子服务器311-313。自主服务器310是从终端111可访问的， 并且子服务器311-313是分别从终端112-114可访问的。
图3是适用于(例如),tel(多々某体电话)自主群呼叫或1-1 PoC会 话和自主PoC会话的多服务器配置的示例。
服务于终端112-114的服务器311-313可根据被服务用户的预订
9和服务提供商的本地策略来修改所接收的服务响应消息(2 0 0 OK) 351-353的内容。
自主服务器310汇总来自子服务器311-313的所接收响应 322-324，并且可在向终端1 111发送OPTIONS响应321之前应用群策 略，如预订选项和服务提供商的本地策略。
在所述实施例中，本发明基本上适用于蜂窝上PoC按键通话。本 领域的技术人员将发明的概念应用于多个其它网络场景，例如3GPP多 々某体电话、固tel自主群等。
下面^^人RFC 3261摘录的OPTION方法的详细描述。
SIP方法OPTIONS允许UA (用户代理)向另 一个UA或代理服务器查 询其能力。这允许客户端发现与所支持方法、内容类型、扩展、编解 码器等有关的信息，而无需使另一方"振铃"。例如，在客户端将请 求(Require)报头字段插入列示它不确定目标UAS (用户代理服务器)是 否支持的选项的INVITE之前，客户端可采用OPTIONS查询目标UAS以 便查看这是否在被支持(Supported)报头字段中返回。所有UA必须支 持OPTIONS方法。
OPTIONS请求的目标通过Request-URI来识别，其可识别另一个 UA或SIP服务器。如果OPTIONS针对的是代理服务器，则设置 Request-URI而没有用户部分，这与对于REGISTER请求设置 Request-URI的方式相似。
备选地，接收具有Max-Forwards才良头字段值为0的OPTIONS请求 的服务器响应该请求，而不管Request-URI。
这种行为是与HTTP/1. 1 —样的。通过发送具有递增Max-Forwards 值的一系列OPTIONS请求，这种行为可用作"跟踪路由"功能性以便 检查各跳服务器的能力。
如一般UA行为情况，如果OPTIONS没有产生响应，则事务层可返 回超时误差。这可指明目标不可达、因而不可用。
OPTIONS请求可作为已建立对话的一部分而发送，以便向对等体查询稍后可用于对话的能力。
OPTIONS请求被使用如RFC 3261第8.1. 1小节中论述的SIP请求 的标准规则来构成。
联系(Contact)报头字段可存在于OPTIONS中。
应当包含接受(Acceptance)报头字段，以便指明UAC(用户代理客 户端)希望在响应中接收的消息主体的类型。这通常设置成用于描述 UA的媒体能力的格式，例如SDP(应用/sdp)。
对OPTIONS请求的响应^^底定为至原始请求中的Request-URI的 范围。但是，仅当OPTIONS作为已建立对话的一部分发送时，才保证 将来的请求才由生成OPTIONS的服务器接收。
示例OPTIONS请求 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
对OPTIONS的响应使用如RFC 3261第8. 2. 6小节中论述的SIP响 应的标准规则来构成。所选的响应代码必须与请求是INVITE时所选的 相同。也就是说，如果UAS准备接受呼叫，则返回200 (OK),如果UAS 忙，则返回486 (在这里为忙)，等。这允许OPTIONS请求被用于确定UAS的基本状态，它可以是关于UAS是否将接受INVITE请求的指示。
在对话中所4妄收的OPTIONS "^青求生成200 (0K)响应，该响应与在 对话外部所构成的响应相同，并且对于对话没有任何影响。
OPTIONS的这种使用因OPTIONS和INVITE请求的代理处理的差异 而具有限制。虽然分叉(forked) INVITE可引起返回多个200 (OK)响应， 4旦是分叉OPTIONS ^5l引起单个200 (0K)响应，因为它由代理使用非 INVITE处理来对待。关于标准细节，参见RFC 3261第16.7小节。
如果对OPTIONS的响应由代理服务器生成，则代理返回200 (OK)， 列示出服务器的能力。
响应不包含消息主体。
允许(Allow)、接受(Accept)、接受-编码(Accept-Encoding)、接 受-语言(Accept-Language)和被支持(Supported)才艮头字段应当存在 于对OPTIONS的200 (OK)响应中。如果响应由代理生成，则当允许才良 头字段不明确时应当将其省略，因为代理是方法不可知论的。联系报 头字段可存在于200 (0K)中，并且具有与3xx响应中相同的语义。也 就是说，它们可显示一组到达用户的备选名称和方法。可存在告警 (Warning)才艮头字段。
可发送消息主体，其类型由OPTIONS请求中的接受报头字段来确 定(如果接受报头字段不存在，则应用/sdp为缺省)。如果类型中包括 能够描述^某体能力的类型，则UAS为该目的应当将主体包含在响应中。 在RFC 3264中描述了关于在应用/sdp的情况下构成这种主体的细节。
由UAS生成的示例OPTIONS响应(与上述请求对应)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未示出)
权利要求
1.一种在电信网络中确定由构成组(110)的多个多媒体终端(111-114)所支持的多媒体能力的方法，其特征在于以下步骤-接收(201)来自第一多媒体终端(111)的第一服务询问消息(121)；-向所述组(110)中的其它多媒体终端(112-114)中的至少一个发送(202)第二服务询问消息(131，141，151)；-从所述其它多媒体终端(112-114)接收(203)作为对所述第二服务询问消息(131，141，151)的响应的第一服务响应消息(132，142，152)；-分析(205)所述第一服务响应消息(132，142，152)中的所接收的能力；-确定(206)能力的公共集合；-向所述第一多媒体终端(111)发送作为所述第一服务询问消息(121)的响应的第二服务响应消息(122)，所述第二服务响应消息(122)包括所述能力的公共集合的。
2. 如权利要求l所述的方法，其中，确定所述能力的公共集合的 所述步骤还包括应用策略的步骤。
3. 如权利要求2所述的方法，其中，所述策略是以下任一个或者 其组合画系统策略； -群策略； -订户策略。
4. 如权利要求1所述的方法，还包括存储(204)所接收的能力的 步骤。
5. 如权利要求4所述的方法，还包括以下步骤-接收来自第二多媒体终端(112)的第三服务询问消息(171);-向所述第 一多々某体终端(111)发送第四服务询问消息(171);-从所述其它多^ 某体终端(lll)接收作为对所述第三服务询问消 息(171)的响应的第三服务响应消息(172);-连同所存储的能力分析所述第三服务响应消息(172)中的所接 收的能力；画确定能力的第二公共集合；-向所述第二多媒体终端(112)发送作为所述第四服务询问消息 (121)的响应的第四服务响应消息(173)，所述第四服务响应消息(17 3) 包括所述能力的第二公共集合的。
6. 如权利要求3或5所述的方法，其中，所述服务询问消息(121, 131， 171)是SIP OPTIONS请求，并且服务响应消息(122, 132， 172) 是SIP 200 0K响应。
7. 如以上权利要求中的任一项所述的方法，其中，所述组(110) 中的所述多i某体终端(111-114)参与多i某体会议呼叫。
8. —种在电信网络中/人包括多个多々某体终端(111-114)的组(IIO) 可访问的多^某体应用服务器(100)，其中，所述服务器(100)的特征在 于它适合于-响应从第一多i某体终端(lll)所接收的服务询问消息(121)，从 所述组(110)中的至少一个第二多i某体终端(112-114)收集能力； -分析所收集的能力，并且确定能力的公共集合。 -向所述第一多媒体终端(112-114)返回包括所述能力的公共集 合的服务响应消息(122)。
9. 如权利要求8所述的多々某体应用服务器(100)，还包括适合 存储所收集的能力的存储器区域(105)。
10. 如权利要求9所述的多4某体应用服务器(100)，还适合当确定 所述能力的公共集合时应用策略。
11. 如权利要求10所述的多i某体应用服务器(100),还适合连同 所述存储器区域(105)中已经存储的能力分析所述所收集的能力。
12. 如权利要求8至12中的任一项所述的多媒体应用服务器 (310-313),还适合于可连接到至少一个其它多媒体应用服务器 (310-313)。
13. —种包括相互连接的如权利要求12所述的多々某体应用服务器 的多个多媒体应用服务器(310- 313)的系统(3 0 0)。
14. 如权利要求13所述的系统(300)，其中，所述服务器(310-313) 在取决于应用的配置中相互连接。
15. 如权利要求14所述的系统(300),其中， 一个服务器是自主 服务器(310),而其它服务器是连接到所述自主服务器(310)的子服务 器(311-313)，并且所述自主服务器(310)还适合汇总从所述子服务器 (311-313)所接收的服务响应消息(322-324)。
全文摘要
本发明涉及用于处理电信系统中的多媒体会议呼叫的系统和方法。为了使组(110)中的第一终端(111)确定组(110)中的至少其它终端(112-114)的能力，可向其它终端(112-114)发送查询消息。当使用SIP(会话初始协议)时，查询通过发送OPTIONS消息的方法来执行。这种方法的限制在于，组中的各终端(111)需要向组中的所有其它终端(112-114)发送查询，以便确定彼此的能力。本发明包括公共服务器(100)，它适合收集与组中的终端(112-114)的能力有关的信息，并且确定发送给第一终端(111)的能力的公共集合。
文档编号H04L29/06GK101682617SQ200880015462
公开日2010年3月24日 申请日期2008年4月21日 优先权日2007年5月11日
发明者J·霍尔姆, M·斯蒂尔 申请人:艾利森电话股份有限公司