SIP会议框架(如draft-ietf-sipping-conferencing-framework-05.txt中 所定义的)定义了参与者可如何创建并加入SIP多媒体会议会话、邀请其 他参与者到该会话、从该会话中移除参与者、获知该会话中的其他参与者 等等的基本过程、功能和体系结构。会议框架已经被采用于很多基于SIP 的会议标准，比如3GPP R6 IMS(第三代合作伙伴项目第六版因特网协议 (IP)多媒体子系统)会议服务(如TS 24.147中所指定的)、OMA-PoC (开放移动联盟-基于蜂窝系统的即按即说)以及OMA-IM(开放移动联 盟-即时消息收发)。
以上框架描述了IETF(因特网工程任务组)规范RFC(请求注解) 3264中所规定的SDP(业务描述协议)提议/应答机制(offer/answer mechanism)可如何用于添加、移除和修改媒体流及其在多媒体会议会话 中的属性。
在多媒体会议会话中，用户应当能够在一个特定媒体(例如，PoC音 频、IM、全双工音频、全双工视频等)的情况下启动会话并在以后添加另 一媒体。会议控制功能然后应当将所添加的媒体传送到会议会话中的其他 参与者，例如，通过IETF RFC 3311中所描述的在SIP re-INVITE(重新 邀请)或SIP UPDATE(更新)请求中的SDP提议。以这样的方式，其他 参与者得知新的媒体已经被添加并且他们可以在会话中开始使用该新的媒 体。
另一方面，参与者还可以使用相同的SDP提议/应答机制来仅修改该 参与者与会议的中央控制点(例如，SIP会议术语中的焦点(focus))之 间的连接部分，即呼叫支路(call leg)。在这种SIP会议框架的会话修改 中，焦点不应当修改其他参与者的媒体会话。例如，在SIP会议框架中， 如果一个参与者想要将全双工音频媒体搁置(put on hold)，则这通过该 参与者与焦点之间的re-INVITE/200 OK中的SDP提议/应答来进行，但是 焦点不应当向其他参与者发送re-INVITE，因为其他参与者并未被搁置， 并且其因而应当能够继续如先前那样的通信。
因而，中央控制点需要能够确定：什么SDP提议应当被传送到其他参 与者，并且在进行重新请求的参与者与焦点之间仅保持什么。在一些媒体 修改中，中央控制点可以基于SDP提议属性对此进行确定。例如，如果一 个参与者将会议会话中的媒体“搁置”，通常中央控制点不应当使其他参 与者搁置，而是在该特定SIP对话内(即在参与者与焦点之间)保持媒体 修改。但是在一些SDP提议的情况下，中央控制点无法知道是否应当进一 步发送媒体修改。例如，如果会议会话包括音频和视频媒体，并且某个参 与者想要仅从他/她的支路移除视频(例如，移动到对视频来说不能提供足 够带宽的小区)，但是其他参与者并没有该限制，即，他们将希望继续具 有音频和视频这二者。
SIP会议框架中当前的SDP提议/应答机制并不足以区分媒体操纵是否 应当被限于一个呼叫支路或被传送到所有参与者。IETF XCON解决目前 类似的使用情况。其中定义了用于媒体控制协议的框架，参与者可以用其 来控制其他参与者的媒体策略，例如，从特定参与者移除视频、减弱一个 参与者的声音(移除音频发送能力)等等。然而，XCON工作进展缓慢， 并且不管怎样，结果都将是参与者与焦点之间的新协议。
从标准化时间日程角度来看，OMA-IM和OMA-PoC所需要的是用于 添加和移除媒体的简单的基于SIP的解决方案，IM和POC不能等待来自 XCON的结果，并且它们并不需要复杂的XCON框架以及媒体策略控制 协议的其它更高级的能力。

因此，本发明的目的是提供一种简单的会话操纵方案，由此可以以简 单并灵活的方式添加和移除媒体成分。
该目的是通过一种控制涉及中央控制点的多方会话中的媒体成分的方 法来实现的，所述方法包括以下步骤：
·在所述多方会话的参与者处选择范围信息，其指定所述多方会话的 成员；
·将所述选择的范围信息添加到会话修改请求；
·将所述会话修改请求传输到所述中央控制点；以及
·响应于所述范围信息，在所述指定的成员处启动媒体修改。
此外，通过用于控制涉及中央控制点的多方会话中的媒体成分的客户 机设备来实现上述目的，所述客户机设备包括：
·用于选择指定所述多方会话的成员的范围信息的选择装置；
·用于将所述选择的范围信息添加到会话修改请求的添加装置；以及
·用于将所述会话修改请求传输到所述中央控制点的传输装置。
另外，通过一种用于提供对多方会话的中央控制的会议服务器设备来 实现上述目的，所述会议服务器设备包括：
·检测装置，用于在所接收的会话修改请求中检测范围信息，所述范 围信息指定所述多方会话的成员；以及
·启动装置，用于响应于所述范围信息，启动针对由所述范围信息所 指定的所述成员的媒体修改。
进一步地，通过一种计算机程序产品来实现上述目的，当运行在计算 机设备上时，所述计算机程序产品包括用于生成以上方法的选择、添加和 传输步骤的代码装置。此外，通过一种计算机程序产品来实现上述目的， 当运行在计算机设备上时，所述计算机程序产品包括用于生成以上方法的 启动步骤的代码装置。
最后，通过一种用于控制多方会话中的媒体成分的系统来实现上述目 的，所述系统包括上述定义的客户机设备和上述定义的会议服务器设备中 的至少一个。
因此，客户机或参与者可以单独地控制媒体修改的范围，即应当将所 请求的媒体修改应用到多方会话的哪些成员。例如，可以由进行请求的参 与者来选择是将媒体修改应用到整个会议还是仅应用于客户机与会议服务 器(即中央控制点)之间。在这种情况下，一个或多个媒体成分可以被进 行请求的客户机在本地或者对于整个会议而丢弃。
根据第一方面，所述范围信息可以被添加为会话修改请求的新的报头 参数。
根据第二方面，所述范围信息可以被添加为会话修改请求的属性。举 例来说，该属性可以是SDP属性并且该范围信息然后可以被添加为a-行值 (a-line value)。
在特定的例子中，所述范围信息可以指定是将媒体修改仅应用于该参 与者还是应用于多方会话的所有成员。
根据第三方面，所述范围信息可以被添加为应当向其应用媒体修改的 那些参与者的地址列表。举例来说，该地址列表可以包括至少一个SIP统 一资源指示符(URI)。
在以上第一到第三方面中，所述会话修改请求可以是SIP re-INVITE 或SIP UPDATE请求。
根据第四方面，所述会话修改请求可以标识应当使用所述范围信息来 联系第三方的接收方。这里，所述会话修改请求可以包括用于通知中央控 制点将要修改现有对话而不是创建新的对话的报头参数。作为附加选项， 所述会话修改请求可以包括被叫方能力信息，其指示将要以何种方式修改 所述现有对话。在第四方面，所述范围信息然后可以被添加为地址列表。 举例来说，该地址列表可以包括至少一个SIP URI。
在从属权利要求中进一步限定了有利的修改。
附图说明
下面将参照附图，基于实施例更详细地描述本发明，在附图中：
图1示出了指示在其中可以实现本发明的多方会议体系结构的示意 图；
图2根据优选实施例示出了媒体修改系统的示意框图；
图3示出了如第二实施例中所使用的re-INVITE请求的例子的列表；
图4示出了如第三实施例中所使用的SDP属性的例子的列表；
图5示出了如第四实施例的第一例子中所使用的REFER(提及)请 求的例子的列表；以及
图6示出了如第四实施例的第二例子中所使用的嵌套的REFER请求 的例子的列表。

现在将在如图1中所示的SIP多方会议体系结构的基础上描述优选实 施例。
在本说明书中，术语“会议”意在指定多方会话的情况，其中被称为 焦点50的单个控制点(其可以是SIP用户代理)通过相应的呼叫支路70 来维护与每个参与者P1 10到P4 40的对话。每个参与者是运行在客户计 算机设备或终端设备上的软件元件或例程，其将用户或装置连接到会议。 其最低限度实现SIP用户代理，但也可以实现用于附加功能的非SIP特定 机制。该SIP用户代理可以是PC应用、SIP hardphone(硬体电话)或 PSTN(公共交换电话网络)网关。其也可以是另外的焦点。
焦点50充当会议的中央管理员的角色，并且通过会议URI(例如，标 识会议的焦点50的URI，通常是SIP URI)来寻址。焦点50具有在会议 中维护SIP信令与每个参与者(例如P1 10到P4 40)的关系的逻辑角色。 焦点50以某种方式负责确保每个参与者接收构成会议的媒体。焦点50还 实现会议策略。
会议的状态包括焦点50的状态、连接到该会议的参与者10-40的设置 及其相应对话的状态。会议通知服务被提供作为焦点50的逻辑功能，焦点 50由此可以充当通知方，从而接受对会议状态的预定并且通知订户有关该 状态的改变。
此外，会议策略服务器60可以被提供作为可以存储和操纵会议策略的 逻辑功能。该逻辑功能并不是SIP特有的，并且在物理上不一定存在。其 指的是将协议连接到会议策略的组件，所述会议策略是控制特定会议的完 整的规则集合。
另外，可以提供混合器(未示出)，其接收相同类型的一组媒体流， 并且以类型特定的方式组合其媒体，从而向每个参与者10-40重新分发结 果。
会议服务器是物理服务器，其最低限度含有焦点功能。其还可以包括 会议策略服务器和混合器功能。
如可从图1获知的，SIP会议体系结构的中央组件是焦点50，其导致 星形拓扑。焦点50负责确保构成会议的媒体流对于会议中的参与者10-40 可用。其通过使用一个或多个混合器来实现，每个混合器组合多个输入媒 体流，以便产生一个或多个输出媒体流。焦点50使用媒体策略来确定混合 器的正确配置。
焦点50能访问每个会议的会议策略。实际上，会议策略可以被认为是 描述该会议应当如何操作的数据库。焦点50的责任在于实施这些策略。焦 点不仅需要读取对数据库的访问，还需要知道其何时发生改变。这样的改 变可能导致SIP信令(例如，从使用SIP BYE方法的会议的用户抛出 (ejection))，并且影响会议状态的那些改变将要求使用会议通知服务向订 户发送通知。
每个会议均具有唯一的焦点50和标识该焦点50的唯一URI。对会议 URI的请求被路由到用于该特定会议的焦点50。用户通常通过向会议URI 发送INVITE请求来加入会议。只要会议策略允许，便通过焦点50接受 INVITE请求并且将用户带入该会议。用户可以通过发送BYE消息来离开 会议，如他们在正常呼叫中那样。
类似地，如果会议策略改变以指示在会议中不再允许一参与者，那么 焦点50可以终止与该参与者的对话。焦点50还可以启动IVITE方法来将 参与者带入到会议。
参与者可以使用某种非SIP特定机制(其可以由此影响会议策略)来 与会议策略服务器60通信。这在图1中通过参与者P440与会议策略服务 器60之间的箭头来说明，尽管总是存在会议策略，然而其并不需要在任何 特定的会议中都可用。
焦点50与会议策略之间的接口以及会议策略服务器60与会议策略之 间的接口是非SIP特定的。出于基于SIP的会议的目的，这些接口充当会 议中所涉及的逻辑角色，这与表示物理分解(physical decomposition)形 成对比。
会议URI是唯一的，以便没有两个会议具有相同的会议URI。其可以 是SIP URI。围绕URI的上下文信息(例如，SIP报头参数)可以指示该 URI表示会议。当SIP请求被发送到会议URI时，该请求被路由到焦点 50。会议URI可以代表长期的(long-lived)会议或者利益集团，例如“sip： discussion-on-dogs@example.com”。由该URI标识的焦点将总是存在， 并且总是在管理会议，无论当前加入任何参与者。其它会议URI可以代表 短期的(short-lived)会议，例如ad-hoc(特定)会议。被叫方能力参数 还可以用于指示焦点50支持会议通知服务。这可以通过声明与会议URI 关联的呼叫方偏好特征参数中的相关包以及SIP SUBSCRIBE(预订)方 法的支持来实现。
如已经在图1中提及并示出的，焦点50是会议的中心。会议中所有的 参与者10-40均通过SIP对话被连接到该焦点。焦点50负责维护与其连接 的对话。其确保对话被连接到允许参与到会议中的一组参与者，如成员关 系策略所定义的。焦点50还使用SIP来操纵媒体会话，以便确保每个参与 者均获得对于该会议的所有媒体。为此，焦点50使用混合器。通过该交互， 其确保所有有效的参与者10-40均接收到媒体流的副本，并且每个参与者 向混合器上的端口和IP地址发送媒体，该混合器使该媒体与会议中的其它 媒体进行适当的混合。
每个会议由焦点50所管理的一组特定的媒体组成。例如，会议可以含 有视频流和音频流。构成会议的一组媒体流可以通过参与者10-40来改变。 当会议中的该组媒体改变的时候，焦点50将需要向每个参与者生成 re-INVITE，以便对每个参与者添加或移除媒体流。参与者可以使用SIP re-INVITE来添加或移除媒体流。这是使用用于向会话添加媒体流的标准 提议/应答技术来完成的。这将触发焦点生成其自己的向会议的其他参与者 10-40的re-INVITE。
图2示出了一示意框图，其指示焦点50或其相应会议服务器硬件设备 以及参与者10或其相应客户机硬件设备的单元或功能性，这些单元或功能 性参与所提议的第三方会话修改方案，由此参与者10可以易于以灵活的方 式操纵媒体成分。
根据图2，参与者10包括选择单元或功能性102，用于选择所期望的 媒体修改的范围，即应当向其应用媒体修改的特定会议参与者。该选择可 以通过在相应客户机设备处所提供的软件功能性或硬件输入功能来控制。 响应于这样的控制或输入操作，选择功能性102生成范围信息SoM(修改 范围)，其通过消息生成单元或功能性104而被添加到会话修改请求。该 请求可以是任何适当的请求，其可以被用于启动任何类型的会话修改。下 面基于示例性SIP会议体系结构解释了这样的请求的例子。
然后，基于会议URI，通过参与者10的消息信令单元或功能性106 将具有所添加的范围信息SoM的增强的会话修改请求发信号或路由到焦 点50。在焦点50处，增强的会话修改请求被类似的消息信令单元或功能 性506接收，并被提供给检测范围信息SoM的范围检测单元或功能性502。 所检测到的范围信息SoM被提供给焦点的消息生成单元或功能504，结合 相应的混合器功能性(未示出)，通过消息信令功能性506启动针对范围 信息SoM中所指定的那些参与者的所请求的媒体修改。
注意到，参与者10的以上单元或功能性102、104和106以及焦点50 的以上单元或功能性502、504和506可以被分别实现为协作或集成于参与 者10和焦点50的相应控制程序(例如，SIP用户代理等)的软件例程或 组件。作为可选方案，以上所列出的单元或功能性可以被分别实现为相应 的客户机设备或会议服务器设备的硬件单元。当然，还可以在其他参与者 20-40中的一些或全部中提供以上单元或功能性102、104和106。
下面描述不同的实施例，可以基于消息类型和消息部分(其传达以上 范围信息SoM)对其进行区分。
根据第一至第三实施例，re-INVITE或UPDATE请求被修改，以便 向参与者提供容易并灵活的方式来选择性地修改会议的媒体成分。当将要 修改现有会话并且没有添加或移除参与者的时候，使用这些机制。 Re-INVITE或UPDATE请求被用于修改会话中的媒体。对网络来说，视 情况而支持UPDATE方法，并且参与者或客户机在会话建立期间可以得 知网络能力。尽管为简化起见，UPDATE方法并不总是作为re-INVITE 的替代方法而在文中被提及，然而结合第一至第三实施例，应当将其理解 为对所有使用re-INVITE的情况的可选方案。
作为特定的例子，这里建议re-INVITE请求含有作为范围信息SoM 的这样的参数，即该参数指示客户机所提议的媒体修改是否应当被应用于 整个会话或仅应用于进行请求的客户机。可以在SIP报头中或者在INVITE 或UPDATE请求的SDP有效载荷中传达该指示。
在第一实施例中，引入了新的SIP报头，例如Media-Handling (Conference/Cilent)(媒体-处理(会议/客户机))。由于一个INVITE 请求可以用于修改若干媒体，因此可以将SIP报头参数值应用于在 re-INVITE中协商的所有媒体。在re-INVITE请求的一些媒体修改目的在 于整个会议而一些目的仅在于参与者自己的媒体或呼叫支路的情况下，参 与者需要发送单独的re-INVITE请求。
作为第一实施例的另外的选项，一些已经存在的SIP报头，例如 Request-Dispositon(请求-处置)SIP报头，可以被用于传达范围信息 SoM。
在第二实施例中，SIP URI列表服务被建议用于传达范围信息SoM。 在这种情况下，SIP INVITE/UPDATE请求含有SIP URI列表作为请求有 效载荷。SIP URI列表被用于告知应当将媒体修改应用于哪些参与者。SIP URI列表还可以含有会议URI，其指示将媒体修改应用于所有会议参与者。 类似于第一实施例，缺省地，所有提议的媒体修改(图3中的多重m-行) 被应用于SIP URI列表中所给出的参与者。如果参与者想要向整个会议添 加某种媒体，而仅向参与者的子集添加其它媒体，则需要两个单独的 re-INVITE/UPDATE。
除了如在“draft-ietf-sipping-uri-services-05.txt”中所指定的SIP URI 列表之外，在re-INVITE/UPDATE请求中可能需要一些附加的指示，以 便通知焦点50它应当如何使用SIP URI列表信息。SIP URI列表可能由于 一些其它的原因已经被包括在re-INVITE/UPDATE请求中。因此，组合 所建议的机制是可能的，例如SIP URI列表和SIP报头、SIP URI列表和 SDP属性，或者另外SIP URI列表本身可以含有新的字段，其指示为此特 定目的而使用该列表。
图3根据第二实施例示出了re-INVITE请求的示例列表，其含有两个 主体，用于PoC服务的SDP和SIP URI列表。
在第三优选实施例中，新的SDP属性，例如Conference/Client-only(会 议/仅客户机)或media-treatment：Conference/Client-only(媒体-处理：会 议/仅客户机)被引入用于传达范围信息SoM，例如，作为a-行值。
图4示出了所建议的SDP属性的例子的列表。在这种情况下，新的 a-行值“conferene(会议)”指示该媒体修改应用于整个会议，并且新的 值“client-only(仅客户机)”指示该媒体修改应当仅被应用在该特定的进 行请求的参与者与会议服务器之间。
该新的SDP属性较为灵活，因为参与者可以将若干媒体包括到相同的 re-INVITE中，并且请求对每个媒体进行不同的处理。会议服务器，即焦 点50，可以立即协商自己的支路修改，而用于整个会议的新媒体可能花费 一些时间。
根据第四实施例，如IETF RFC 3515中所规定的，REFER方法被用 作会话修改请求，范围信息被添加到该请求中。
特别地，可以引入新的SIP报头“Alternates(可选方案)”(相比于 “Replaces(替换)”)。在SIP REFER方法中使用该报头，以便通知受 托方(referee)，即焦点50：由于接收到REFER而发送的INVITE应该 修改现有的对话，而不是创建新的对话。另外，在REFER方法中，根据 Refer-to报头中的联系URI可以使用被叫方能力。这些被叫方能力以及新 的Alternates报头向焦点50指示应当以何种方式修改对话。
作为附加的选项，SIP URI列表服务可以用于REFER，以便向会议会 话的所有参与者10-40生成re-INVITE。利用SIP URI列表服务，还有可 能请求生成re-INVITE并仅将其仅发送到会议参与者中的一些参与者。在 这种情况下，进行请求的参与者或客户机可以将参与者的列表包括到 REFER请求中作为SIP URI列表。
当参与者想要修改其他参与者的会话时，总是可以使用这一新的基于 REFER的机制，该机制利用Alternates报头。如果参与者想要修改其自已 到焦点50的呼叫支路70，则其使用规则的SDP提议/应答机制，如在第三 优选实施例中所解释的。
图5根据第四实施例示出了REFER请求的第一例子的列表，其中用 户A想要丢弃来自音频/视频多媒体会议会话中的所有参与者的视频。用户 A向焦点50发送REFER请求。该REFER请求含有具有焦点URI的 Refer-to报头。Refer-to中的焦点URI指示该方法应当被发送到当前处于 与该焦点50的会话中的所有参与者。
焦点50然后向当前处于会话中的每个参与者生成re-INVITE。另外， 基于每个参与者的会话中当前所协商的媒体，焦点50向re-INVITE添加 SDP提议。基于REFER请求的Refer-To报头中所给出的被叫方能力(在 该例子中是音频)，焦点50生成仅包括音频媒体的SDP提议。作为来自 每个参与者的响应，丢弃来自所有参与者的视频。
在第四实施例的第二例子中丢弃视频的另一种方式是向焦点发送嵌套 的REFER。
图6根据第二例子示出了REFER请求的列表。嵌套的焦点生成对于 每个参与者的REFER。该第二REFER包括新的Alternates报头，参与者 基于此生成re-INVITE返回给焦点。该re-REVITE包括丢弃来自进行的 对话的视频媒体的SDP提议。
作为特定的例子，以上结合第一至第四实施例所介绍的简单并灵活的 媒体修改机制可以在OMA PoC 2.0中实现。由此，提供了一种用于PoC 特征的新媒体，其中一个会话可以含有若干媒体。
总之，已经描述了一种用于控制涉及中央控制点的多方会话中的媒体 成分的方法、系统、客户机设备、会议服务器设备以及计算机程序产品。 在所述多方会话的参与者处，选择指定所述多方会话的成员的范围信息， 并将其添加到会话修改请求。该会话修改请求被传输到中央控制点，该中 央控制点响应于所述范围信息在指定的成员处启动媒体修改。由此，客户 机可以控制是将媒体修改应用于整个会议、所选择的参与者还是仅应用于 客户机本身与会议服务器之间。
应当注意，本发明并不限于上述优选的基于SIP的实施例，而是可以 结合对于多方会话的任何类型的媒体修改来应用，其中会话修改请求可以 用于修改媒体成分。可以使用或新引入任何报头或有效载荷部分或参数， 以便添加和传达所建议的范围信息。优选实施例因而可以在所附权利要求 的范围内变化。