进行多方通信的方法、系统及装置和发布事件状态的方法

摘要

本发明公开了一种进行多方通信的方法、系统及装置和发布事件状态的方法，其中，进行多方通信的方法包括：应用服务器接收到携带本次多方通信的群组条件的多方通信请求后，根据从该请求中获取本次多方通信的群组条件对本次多方通信进行控制。本发明实施例提供的方法、系统及装置，可以设置多方通信的群组条件，通过群组条件限制多方通信的参与方。本发明提供的发布事件状态的方法包括：应用服务器在接收到携带资源的事件状态和授权信息的发布消息后，根据所述的授权信息对所述资源的事件状态的订阅权限进行控制。该方法能够对事件状态进行订阅限制。

说明书

技术领域

本发明涉及在通信领域中的多方通信技术，特别涉及一种进行多方通信 的方法、系统及装置和发布事件状态的方法。

背景技术

随着会话初始化协议(SIP，session initiation protocol)技术的发展，在 通信领域中进行多方通信，如进行包含视频、语音或文本等媒体类型的多方 通信会议变得越来越流行，很多通信业务都支持多方通信，例如即时消息 (IM，Instant Messaging)业务和一键通话(PoC，Push-To-Talk over cellular) 等。多方通信主要指集中式的会议(Centralized Conferencing)，有应用服 务器对多方通信进行集中控制。按参与者的类型多方通信主要有两种方式： 一种是预定义群组(Pre-defined Group)方式，另一种是临时群组(Ad hoc Group)方式。

在预定义群组方式中，预定义群组包含一个成员列表，使用一个群组标 识(ID)来标识这个群组，当使用SIP邀请(SIP INVITE)消息发起多方通 信时，则由发起方向多方通信的应用服务器发送携带群组ID的SIP INVITE 消息，请求建立多方通信。应用服务器中存储群组ID与成员列表的对应关 系，根据对应关系确定接收到消息携带群组ID对应的成员列表，将该消息 发送给成员列表对应的各个成员，成员确认后应用服务器为发起方和成员列 表对应的各个成员建立多方通信。

在临时群组方式中，由于应用服务器没有存储群组ID与成员列表之间 的对应关系，所以发起方向多方通信的应用服务器发送SIP INVITE消息， 请求建立多方通信时，需要携带临时群组的成员列表。应用服务器接收到该 消息后，根据携带的成员列表向对应的各个成员转发该请求，成员确认后应 用服务器为发起方和成员列表对应的各个成员建立多方通信。

在英特网工程任务组(IETF，Internet Engineering Task Force)制定的 规范中，可以通过SIP消息的消息体包含临时群组的成员列表，用以邀请多 个成员参加多方通信，具体为：在SIP INVITE消息中包含一个 multipart/mixed的消息体，其中包含了两个具体的消息体部分：一个是 application/sdp消息体，用以描述多方通信，如会话的媒体消息；另一个是 application/resource-lists+xml消息体，用以描述参与多方通信的成员的统一 资源标识符(URI，uniform resource identifier)列表。

以下以多方通信会话为例进行举例说明。

图1为现有技术中采用SIP技术建立会话的方法流程图，包括的网络实 体有会话发起方、应用服务器(可以为IM、PoC或电话会议服务器等)以 及多个会话参与方，其具体步骤为：

步骤101、会话发起方向应用服务器发起SIP INVITE请求，其中携带 multipart/mixed消息体。

步骤102、接收到该请求的应用服务器向会话发起方返回确认消息，即 200OK响应。

步骤103、应用服务器根据该请求携带的multipart/mixed消息体中的临 时群组列表确定会话参与方，分别向会话参与方发送SIP INVITE请求，该 请求与步骤101中的请求类似，都包含multipart/mixed消息体，区别在于， 在multipart/mixed消息体中不包含临时群组列表。

为简要起见，一些公知的消息流步骤如ACK响应等在图中被省略。

在实际建立多方通信时，多方通信的会话发起方希望给参与方设置限制 条件，可称之为群组会话条件(Conference Policy或者Group Rules)，或简 称群组条件，例如：多方通信的群组最大成员数、是否允许成员邀请其他成 员参与、是否允许其他成员主动加入或/和是否允许匿名等群组条件。但是， 从上述方案可以看出，在采用临时群组方式建立多方通信时，通过现有的 SIP消息，如SIP INVITE请求或SIP订阅(SIP SUBSCRIBE)请求等无法 满足这一需求。另外，对于采用预定义群组方式建立多方通信时，通过SIP 消息，也无法更改在应用服务器中已经预先设置的群组条件。

更进一步地，对于采用两种方式建立多方通信时，群组中的成员还有通 过订阅获取针对自己的群组条件的需求，目前，也无法通过现有的SIP消息 完成这种需求。

发明内容

本发明实施例提供了一种进行多方通信的方法，该方法能够设置多方通 信的群组条件，通过群组条件控制多方通信和限制多方通信的参与方。

本发明实施例还提供了一种进行多方通信的系统，该系统能够设置多方 通信的群组条件，通过群组条件控制多方通信和限制多方通信的参与方。

本发明实施例还提供了一种进行多方通信的服务器，该服务器能够根据 接收到的SIP消息设置多方通信的群组条件，通过群组条件控制多方通信和 限制多方通信的参与方。

本发明实施例还提供了一种进行多方通信的客户端，该客户端能够根据 发起设置多方通信的群组条件的SIP消息，通过群组条件控制多方通信和限 制多方通信的参与方。

本发明实施例还提供一种发布事件状态的方法，该方法能够对事件状态 进行订阅限制。

本发明实施例的实现方案如下：

一种进行多方通信的方法，该方法包括：应用服务器接收到携带本次多 方通信的群组条件的多方通信请求后，根据从该请求中获取本次多方通信的 群组条件对本次多方通信进行控制。

一种进行多方通信的系统，该系统包括应用服务器和客户端，其中，

应用服务器，用于接收客户端发送的多方通信请求，获取该请求中的群 组条件，且对应于群组条件建立多方通信后，根据群组条件对多方通信会话 进行控制，或对客户端发送的修改多方通信请求进行处理；

客户端，用于向应用服务器发送包含群组条件的多方通信请求或修改多 方通信请求。

一种进行多方通信的客户端，包括收发模块和群组条件生成模块，其中，

群组条件生成模块，用于生成多方通信的群组条件，发送给收发模块；

收发模块，用于将从群组条件生成模块接收到的群组条件包含在多方通 信请求中发送出去。

一种进行多方通信的服务器，包括：收发模块、存储群组条件模块以及 控制模块，其中，

收发模块，用于接收携带群组条件的多方通信请求后，将携带的群组条 件发送给存储群组条件模块，并将该请求转发给控制模块处理，接收控制模 块发送的响应消息后，转发出去；

存储群组条件模块，用于从收发模块接收群组条件并存储，在多方通信 过程中提供群组条件给控制模块；

控制模块，用于根据从存储群组条件模块获取的群组条件控制多方通信 的会话。

一种发布事件状态的方法，该方法包括：

应用服务器在接收到携带资源的事件状态和授权信息的发布消息后，根 据所述的授权信息对所述资源的事件状态的订阅权限进行控制。

本发明实施例在发起建立多方通信时，多方通信的发起方可以通过SIP 消息携带群组条件，在应用服务器设置多方通信的群组条件，从而在建立多 方通信或在多方通信过程中，应用服务器根据群组条件控制多方通信和限制 多方通信的参与方。因此，本发明实施例提供的方法、系统、服务器及客户 端，可以设置多方通信的群组条件，通过群组条件控制多方通信和限制多方 通信的参与方。更进一步地，本发明实施例还可以在多方通信过程中通过 SIP消息携带群组条件更新应用服务器中的多方通信的群组条件。

另外，本发明实施例提供的发布事件状态的方法，可以在发布消息中携 带授权信息，从而根据携带的授权信息对发布消息中携带的资源的事件状态 进行权限控制。

附图说明

图1为现有技术中采用SIP技术建立会话的方法流程图；

图2为本发明实施例application/conference-policy+xml消息体结构示意 图。

图3本发明实施例在临时群组方式下进行会话的方法流程图；

图4为本发明实施例控制功能服务器控制会话的方法流程图；

图5为本发明实施例参与功能服务器控制会话的方法流程图；

图6为本发明实施例会话发起者修改群组条件的方法流程图；

图7为本发明实施例会话参与成员订阅群组条件的方法流程图；

图8为本发明实施例在预定义群组会话和会议情况下，进行会话的方法 流程图；

图9为本发明较佳实施例SIP客户端2向会话创建者发送秘密消息的处 理方法流程图；

图10为本发明实施例应用在Publish场景中的订阅呈现信息的方法流程 图；

图11为本发明实施例进行多方通信的系统示意图；

图12为本发明实施例进行多方通信的客户端装置示意图；

图13为本发明实施例进行多方通信的服务器装置示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明 实施例作进一步的详细描述。

本发明实施例在多方通信发起方向多方通信的应用服务器发送多方通 信会话请求时，携带群组列表信息的同时携带群组条件，该群组条件包括公 用的群组条件和/或针对特定群组成员的条件，多方通信的应用服务器根据 接收到该请求携带的群组列表信息确定群组中的成员，根据接收到该请求携 带的群组条件，为确定的成员发送相应的请求，得到确认响应后，将成员加 入到多方通信中。

在本发明实施例中，多方通信会话请求携带的群组列表信息可以为群组 列表的标识(在预定义群组方式下)以及群组列表(在临时群组方式下)。

在本发明实施例中，在多方通信的过程中，多方通信的群组成员也可以 向多方通信的应用服务器发送携带群组条件的更改多方通信会话请求，多方 通信的应用服务器根据接收到的该请求携带的群组条件确定是否匹配已经 存储的群组条件，如果是，则可以更新当前多方通信的群组条件。更进一步 地，还可以将更新后的群组条件携带在多方通信请求中发送给对应的多方通 信的群组成员。

在本发明实施例中，多方通信的群组成员还可以订阅多方通信中与自身 相关的群组条件，从而方便多方通信的群组成员获悉在多方通信会话中与自 身相关的群组条件。

以下以建立多方通信采用SIP为例对本发明实施例进行详细说明。

多方通信会话请求可以是建立多方通信的INVITE请求，或者是在会话 过程中修改多方通信的重新邀请(re-INVITE)请求，或者是会话建立之前 修改多方通信的更新(UPDATE)请求，还可以是咨询(REFER)请求等。 其中，INVITE等请求可以由多方通信参与方发往应用服务器，也可以由应 用服务器发往多方通信参与方。在多方通信发起方向多方通信的应用服务器 发送SIP INVITE请求时，包含一个multipart/mixed的消息体，其中包含两 个消息体部分：用于描述多方通信会话的媒体信息的application/sdp消息体 和application/conference-policy+xml消息体。application/conference-policy +xml消息体如图2所示，包括的信息项有：群组成员列表、群组信息、公 用的群组条件和针对特定群组成员的群组条件。

其中，群组成员列表包括群组成员的URI(如Tel URI或SIP URI)以 及对应的属性(是否匿名anonymize等)。

群组信息，可以选择为群组信息，包括群组显示名<display-name>和群 组会话主题<subject>。

公用的群组条件，与针对特定群组成员的群组条件二者可以选择其一或 并存，在实际应用中，一般可以并存，其中包括：多方通信的群组成员的最 小个数<min-participant-count>，小于该个数后多方通信取消；多方通信的群 组成员的最大允许参与人数<max-participant-count>，等于该个数后不允许邀 请新成员加入；多方通信的结束条件<session-end-criteria>；是否自动发送群 组信息变更通知<automatic-group-advertisement>；会话最长持续时间 <max-duration>、多方通信允许的时间范围<schedule>；是否首先将所有多方 通信的群组成员设置为静音<mute-all-first>；会话模式，如标识是否立即发 起会话请求，即标识是聊天室群组会话还是即时邀请群组会话。以上可以信 息可以全部或部分的包括在公用的群组条件中。

针对特定群组成员的群组条件，与公用的群组条件二者可以选择其一或 并存，该条件采用<conditions>-<actions>的结构，即满足一定条件时，执 行一定的动作。

相关的<conditions>可以包括：多方通信的群组成员标识<identity>、多 方通信的其它群组成员标识<other-identity>或/和多方通信的临时群组成员 <is-list-member>等。

本发明实施例定义的<actions>包括：是否允许群组成员订阅会议状态 <allow-conference-state>、是否允许群组成员订阅多方通信参与条件 <allow-conference-rule-state>、是否允许群组成员动态邀请其他人参与会话 <allow-invite-users-dynamically>、指示应用服务器是否阻止加入多方通信的 请求<join-handling>、是否允许匿名参与多方通信<allow-anonymity>、是否 具有高优先级的成员<is-key-participant>、是否允许群组成员创建多方通信 的子会议<allow-subconf>、是否允许群组成员在多方通信中使用秘密消息、 或/和是否允许将群组中的其他群组成员全部静音(allow-mute-all)等。

图3为本发明实施例在临时群组方式下进行会话的方法流程图，其中涉 及的网络实体包括：会话发起者，即SIP客户端；SIP应用服务器；会话参 与成员，即SIP客户端1和SIP客户端2。其具体步骤为：

步骤301、SIP客户端向SIP应用服务器发送SIP INVITE请求，该请求 携带临时群组成员列表及对应的群组条件，用于建立起应用服务器与该SIP 客户端之间的会话。

步骤302、SIP应用服务器根据接收到请求中的群组条件为本次会话参 与成员分别生成对应的SIP INVITE请求。

其中每个本次会话参与成员对应的根据群组条件生成的SIP INVITE请 求的消息体可以不相同。如根据群组条件中参与者允许的媒体类型生成SIP INVITE请求的消息体的SDP部分可以不相同，可与部分参与者只建立语音 类型的通信，而其他参与者可同时建立语音和视频类型的通信。另外SIP应 用服务器还可以在给每个参与者发送的SIP INVITE请求的消息体中包含公 用的群组条件和该参与者对应的特定群组条件，每个参与者对应的特定群组 条件也可以不相同。

步骤303、SIP应用服务器将对应于SIP客户端1的SIP INVITE请求发 送给SIP客户端1，其中可以携带或不携带对应于SIP客户端1的群组条件。

如果SIP客户端接收到了群组条件，则可以将其内容显示给用户，或者 还可以在后续的通信过程中根据这些群组条件对用户进行控制。例如：将群 组条件中的群组会话主题显示在SIP客户端界面上，或禁止用户进行群组条 件中不允许的动作，如创建多方通信的子会议，这样避免客户端发送不被允 许的请求，节约了网络资源和时间。

步骤304、SIP应用服务器将对应于SIP客户端2的SIP INVITE请求发 送给SIP客户端2，其中可以携带或不携带对应于SIP客户端2的群组条件。

步骤305、SIP客户端1接收到步骤303发送的请求后，返回响应，即 200 OK。

SIP应用服务器在收到200OK后回送确认(ACK)响应，建立与SIP 客户端1的会话。

步骤306、SIP客户端2接收到步骤304发送的请求后，返回响应，即 200 OK。

SIP应用服务器在收到200 OK后回送ACK响应，建立与SIP客户端2 的会话。

步骤307、SIP应用服务器建立了与SIP客户端、SIP客户端1和SIP客 户端2之间的会话，并对该群组会话进行集中的控制。在会话过程中，群组 成员，如SIP客户端1向SIP应用服务器发送携带更新群组条件的修改会话 (re-INVITE)请求，例如增加视频媒体能力或邀请新群组成员加入等。 re-INVITE请求实际上就是在会话过程中发起的会话内的SIP INVITE请求， 可以用于修改多方通信会话的属性，如会话的媒体类型、通信端口等。

步骤308、SIP应用服务器根据所存储的群组成员对应的群组条件判断 是否允许群组成员发送的re-INVITE请求，如果是，则执行步骤309；否则， 则返回失败响应(在图中未示出)。

步骤309、SIP应用服务器执行该re-INVITE请求，给SIP客户端1增 加视频媒体能力或者向被邀请的成员发起SIP INVITE请求邀请其加入，然 后向发送修改会话请求的该群组成员返回响应，即返回200 OK。

在会话过程中，群组条件可以被更新以更改应用服务器的集中控制行 为。通常只允许会话的发起者如上述的SIP客户端或群组条件中设定的管理 者如上述的SIP客户端1等更新群组条件。会话发起者可以向应用服务器发 送re-INVITE消息，其消息体中携带更新后的群组条件，对现有条件进行替 换或合并。其中可以进一步携带是否替换或合并的指示，应用服务器可以根 据此指示执行群组条件的替换或者合并。在SIP应用服务器执行修改会话请 求时，还可以根据修改会话请求生成对应于本次会话参与成员的re-INVITE 请求，发送给对应的本次会话参与成员，包括本次多方通信会话的发起者。 如更新群组条件后，原先的视频会议现在变成只允许语音了，则应用服务器 向参与者发送re-INVITE请求，其消息体携带更改后的针对每个会话参与成 员生成的群组条件。又如更新的群组条件变为禁止群组参与者A参见，则 应用服务器可以生成断开多方通信会话请求，发送给群组参与者A，禁止其 参与多方通信会话。

除了在会话过程中可以用re-INVITE请求的方式来更新群组条件，在发 送SIP INVITE请求后而多方通信会话还尚未建立时，可以用UPDATE消息 来更新群组条件。

通过群组条件对多方通信会话进行控制是由SIP应用服务器执行的，在 本发明实施例中，SIP应用服务器可以分为参与功能服务器和控制功能服务 器，会话的修改集中在控制功能服务器上进行的。对于临时群组会话，一开 始接收SIP INVITE会话建立请求的应用服务器作为控制功能服务器，其他 参与该临时群组会话的应用服务器为参与功能服务器。对于预定义群组会 话，能够根据群组ID获取群组成员的应用服务器为控制功能服务器，其他 参与该预定义群组会话的应用服务器为参与功能服务器。在本发明实施例 中，控制功能服务器主要处理初始的会话请求并维护群组会话条件，执行接 收到的修改会话请求。

在本发明实施例中，上述的SIP应用服务器实际上就是控制功能服务 器，参与功能服务器对整个会话来说是透明的，没有参与根据群组条件对会 话的控制。

图4为本发明实施例控制功能服务器控制会话的方法流程图，其具体步 骤为：

步骤401、控制功能服务器接收到SIP INVITE请求。

在临时群组会话中，通常客户端会向一个预定的会场(Conf-Factory) 的URI发送SIP INVITE请求，即INVITE sip:Conf-Factory，控制功能服务 器回送302(Moved)响应，并携带控制功能服务器实际分配的会议标识 (Conf-ID)，客户端根据实际分配的Conf-ID，重新发起SIP INVITE请求， 即INVITE sip:Conf-ID，随后建立起客户端和控制功能服务器的会话。

步骤402、该控制功能服务器返回200 OK，在客户端回送ACK后建立 会话。

步骤403、该控制功能服务器获取接收到该请求携带的群组成员列表和 对应的群组条件。

步骤404、该控制功能服务器根据群组成员列表生成对应于群组成员的 SIP INVITE请求，过程为：将SIP INVITE请求的Request URI填充为某个 群组成员的地址(SIP URI或Tel URI)，将From填充为自身的地址以及 To填充为上述成员的地址。还可以在SIP INVITE请求中携带对应上述成员 的群组条件，而目前被邀请的群组成员无法获知本次会话的一些信息，如自 己被允许的权限和群组会话的限制条件等。

在本步骤中，还可以进行一些其他的处理：

A、该控制功能服务器在生成的对应于群组成员的SIP INVITE请求消 息体中继续携带群组成员列表，以让其获悉群组会话中的其他参与方。但是 将接收到请求中的copyControl为bcc和anonymize为true的URI删除，保 留剩余的且根据剩余的生成对应于群组成员的SIP INVITE请求。删除这些 URI是为了实现这些群组成员的隐身或者密送的目的。

B、保留公用的群组条件，将针对各个成员的群组条件转化为针对此成 员的群组条件携带在对应于群组成员的SIP INVITE请求中。

步骤405、该控制功能服务器将处理后获得的针对每个成员的SIP INVITE请求分别发送给对应的群组成员接收。

在发送给各个群组成员的SIP INVITE请求中，可以携带对应于该群组 成员的群组条件，也可以不携带对应于该群组成员的群组条件。如果该请求 携带了群组条件，则群组成员所属的应用服务器(如果不是控制功能服务器 就是参与功能服务器)或群组成员所在的客户端在后续接收到修改会话请求 时可以进行一些过滤处理，这些修改会话请求可以为更改媒体、发送秘密消 息、创造子会议或重新加入会话等，避免客户端发送一些不被允许的请求给 控制功能服务器；而有些则必须到该控制功能服务器进行处理，如邀请群组 成员加入的群组成员个数是否超过了设定的会话参与成员总数等(因为会话 参与成员也会邀请成员加入，实时的成员总数只有该控制功能服务器知道)。

如果该请求没有携带群组条件或在会话过程中群组条件发生了变更，则 群组成员所属的应用服务器或群组成员所在的客户端可以通过群组成员订 阅群组条件的过程来获取到群组条件，这个过程后续进行详细描述。

步骤406、如果在会话过程中，该控制功能服务器接收到会话变更请求， 如邀请其他成员加入、改变媒体类型等会导致会话信息和状态变更的请求， 该控制功能服务器根据接收到请求中携带的群组成员标识和变更类别查找 到所存储的群组条件。

步骤407、该控制功能服务器匹配所存储的群组条件，获取匹配结果。

具体过程为：首先应用公用的群组条件，例如本次会话的最大参与人数 为10，如果当前已经有10个成员参与会话，而其中一个成员使用REFER 请求(SIP消息中的一种)邀请其他成员加入，该控制功能服务器拒绝该请 求。

然后，应用针对特定群组成员的群组条件，其中成员标识对应 <conditions>中的条件，变更类别对应<actions>中的条件，例如，某个群组 条件中的<conditions>/<identity>为此成员的成员标识，或者某个群组条件中 的<is-list-member>为此成员的成员标识，则该条件对应该成员；假设该成员 之前是被踢出本次会话的，其<actions>/<join-handing>条件为false，即不允 许重新加入，当变更类别为重新加入时，该控制功能服务器拒绝该请求。

步骤408、该控制功能服务器根据最终的匹配结果向发送该请求的成员 返回对应的响应，包括接受请求和拒绝请求两种可能。

另外参与功能服务器也可以根据群组条件进行会话的控制，假定参与功 能服务器和控制功能服务器为不同的服务器，实际中如果一个参与者与发起 者归属于同一个应用服务器，则该参与者对应的参与功能服务器就是控制功 能服务器。图5为本发明实施例参与功能服务器控制会话的方法流程图，其 具体步骤为：

步骤501、参与功能服务器接收到SIP INVITE请求。

步骤502、该参与功能服务器判断接收到的SIP INVITE请求是否来自 控制功能服务器，如果是，则执行步骤503；如果否，则执行步骤504。

步骤503、该参与功能服务器获取接收到请求携带的成员标识，向对应 的群组成员发送SIP INVITE请求，请求该群组成员加入会话，结束流程。

如果SIP INVITE请求中包含了群组条件，则参与功能服务器将其缓存 在本地，供后续据此对参与者的请求进行过滤处理。

步骤504、该参与功能服务器获取接收到请求携带的变更类别，查找到 本地缓存的对应的群组条件，执行步骤504。

在本步骤中，如果接收到的SIP INVITE请求不是来自控制功能服务器， 就说明该SIP INVITE请求为更改多方通信会话请求。

步骤505、该参与功能服务器判断变更类别是否与查找到的对应的群组 条件相匹配或该参与功能服务器没有存储有对应的群组条件，如果是，则执 行步骤506；如果否，则返回拒绝该请求的响应。

判断变更类别是否与查找到的对应的群组条件相匹配，即判断是否被群 组条件所允许。该参与功能服务器无法判断目前会话参与人数，因此无法对 “重新加入”以及“邀请其他成员加入”等变更类别进行群组条件匹配处理， 而对于“秘密消息”或“获取会议状态”等变更类别可以进行群组条件匹配。

步骤506、该参与功能服务器根据接收到请求的目的地将该请求转发到 目的应用服务器，即控制功能服务器上进行处理。

步骤507、该控制功能服务器进行群组条件的匹配，根据匹配结果向发 送方返回对应的响应，包括接受该请求或拒绝该请求两种可能。

在该步骤中，如果控制功能服务器不将群组条件发送到会话参与成员所 属的应用服务器，即参与功能服务器，在这种情况下，参与功能服务器就需 要将接收到的所有会话变更请求发送到控制功能服务器去处理。另外接收到 群组条件的客户端，可以进行一些类似地过滤处理。

图6为本发明实施例会话发起者修改群组条件的方法流程图，涉及的网 络实体包括：会话发起者SIP客户端、SIP应用服务器以及会话参与成员SIP 客户端1和SIP客户端2，其具体步骤为：

步骤601、会话过程中，SIP客户端向SIP应用服务器发送SIP re-INVITE 请求，携带群组会话标识和修改后的群组条件。

在本发明实施例中，会话参与成员，如SIP客户端1或SIP客户端2也 可以发送SIP re-INVITE请求，进行群组条件的修改，应用服务器可以根据 对应的授权策略(例如允许SIP客户端1修改)来判断是否允许修改。或者 会话参与成员发送的请求。或者此请求被转发到会话发起者处进行授权，应 用服务器根据授权结果向会话参与成员返回对应的响应。

步骤602、SIP应用服务器根据接收到请求携带的群组会话标识找到所 保存的对应的群组条件并更新。

如果群组条件更新后，需要重新邀请成员，如改变多方通信的媒体类型， 则还可以进行以下步骤：

步骤603～604、SIP应用服务器向会话参与成员分别发送对应的 re-INVITE请求，进一步在请求中还可以携带对应于各个会话参与成员更新 后的群组条件。

另外更新后的群组条件也可以通过通知(NOTIFY)消息发送给各参与 群组成员，具体步骤如图7所示。图7为本发明实施例会话参与成员订阅群 组条件的方法流程图，其具体步骤为：

步骤701、会话进行过程中，SIP客户端2向SIP应用服务器发送订阅 (SUBSCRIBE)请求，订阅群组条件。

该请求用于当群组条件变更时，可以获得群组条件变更通知，其中 SUBSCRIBE请求中可以携带过滤规则，指明希望接收哪些群组条件的变更 通知，如，仅希望接收秘密消息、会话所允许群组成员的个数等相关条件的 变更通知。

步骤702、SIP应用服务器根据接收到请求保存SIP客户端2的订阅信 息。

在保存SIP客户端2的订阅信息之前，还可以对SIP客户端2进行认证 和授权，认证和授权通过后，才能保存SIP客户端2的订阅信息。

步骤703、SIP应用服务器监控群组条件的变更，当监控到群组条件变 更后，根据存储的订阅信息生成NOTIFY消息，该消息携带更新的群组条件， 所述的更新的群组条件是根据过滤规则过滤后的群组条件。

步骤704、SIP应用服务器向SIP客户端2发送NOTIFY消息，携带更 新的群组条件。

图8为本发明实施例在预定义群组会话情况下，进行会话的方法流程 图，其具体步骤为：

步骤801、会话发起者，即SIP客户端发送SIP INVITE请求，携带预 定义群组标识。

步骤802、SIP应用服务器到共享群组管理服务器(Shared Group XDMS， Shared Group XML Document Management System)获取该请求携带的预定义 群组标识对应的群组成员信息和群组条件。

如果SIP应用服务器存储有请求携带的预定义群组标识对应的群组成 员信息和群组条件，则省略该步骤。

如果在步骤801中SIP INVITE请求中也包含有群组成员信息和群组条 件，则与预定义群组标识对应的群组成员信息和群组条件进行合并后，执行 后续步骤。具体的合并方法如群组成员进行并集运算，群组条件采用逻辑与 “AND”运算。

步骤803～807、与图3中的步骤302～306相同。

步骤808、会话过程中，SIP客户端发送SIP re-INVITE请求，携带修改 后的群组条件。

步骤809、SIP应用服务器更新保存的本次会话群组条件，可选地，针 对会话参与成员生成对应的会话条件变更请求，如SIP INVITE请求，可以 修改会话的媒体类型；或者此会话变更请求中还包含了新增的群组成员，则 发送SIP INVITE请求邀请新增的成员加入群组会话。如果在更新的群组条 件中设定了禁止某个正在参与会话的成员继续参与会话，则应用服务器可以 向该成员客户端发送禁止(BYE)请求，断开其连接。

举两个具体实施例进行说明。

实施例1

Alice邀请了5个同学进行IM聊天，她希望仅允许这5个同学再邀请一 些朋友参与会话，但是不希望再邀请的这些朋友再次邀请其他人加入聊天， 同时确定总聊天人数不超过10人，所有参与聊天的人员都不允许匿名，不 允许开子会议，不允许传输秘密消息，会议主题为“Merry Xmas and Happy New Year！”。以下是Alice发起SIP INVITE请求的格式：

INVITE sip:conf-fact@example.com SIP/2.0

Via:SIP/2.0/TCP atlanta.example.com

     ；branch＝z9hG4bKhjhs8ass83

Max-Forwards:70

To:″Conf Factory″<sip:conf-fact@example.com>

From:Alice<sip:alice@example.com>；tag＝32331

Call-ID:d432fa84b4c76e66710

CSeq:1INVITE

Contact:<sip:alice@atlanta.example.com>

Allow:INVITE，ACK，CANCEL，BYE，REFER

Allow-Events:dialog

Accept:application/sdp，message/sipfrag

Require:conference-policy-invite

Content-Type:multipart/mixed；boundary＝″boundary 1″

Content-Length:XXX(填写消息体实际长度)

--boundary 1

Content-Type:application/conference-policy+xml

Content-Disposition:conference-policy

<？xml version＝″1.0″encoding＝″UTF-8″？>

<list-service>

  <list>

    <entry uri＝″sip:bill@example.com″copyControl＝″to″/>

    <entry uri＝″sip:randy@example.net″copyControl＝″to″/>

    <entry uri＝″sip:eddy@example.com″copyControl＝″to″/>

    <entry uri＝″sip:joe@example.org″copyControl＝″cc″/>

    <entry uri＝″sip:carol@example.net″copyControl＝″cc″/>

  </list>

<display-name xml:lang＝″en-us″>Friends</display-name>

<max-participant-count>10</max-participant-count>

<subject>Merry Xmas and Happy New Year！</subject>

  <ruleset>

    <rule id＝″a7c″>

      <conditions>

        <is-list-member/>

      </conditions>

      <actions>

        <join-handling>true<join-handling>

        <allow-anonymity>true</allow-anonymity>

        <allow-subconf>false</allow-subconf>

        <allow-private-message>false</allow-private-message>

        <allow-invite-users>true<allow-invite-users>

      </actions>

    </rule>

  </ruleset>

</list-service>

--boundary 1-

图9为本发明较佳实施例SIP客户端2，即在会话过程中被某个同学邀 请加入的朋友Tom企图再邀请另外一个人加入会话的处理方法流程图，其 具体步骤为：

步骤901、会话过程中，Tom希望向邀请另外一个人Lisa加入会话，其 客户端向所归属的SIP应用服务器2即参与功能服务器发送REFER消息， 其中的REFER-TO字段指定为Lisa的SIP URI。

步骤902、应用服务器2通过SIP/IP Core将该消息路由到控制功能服务 器，即应用服务器1。

步骤903、应用服务器1首先匹配公用的群组条件，如检查是否聊天人 数已经达到上限；然后匹配针对Tom的群组条件，确定Conditions中没有 Tom满足的条件，则确定不允许Tom邀请其他人加入会话。

步骤904、应用服务器1通过SIP/IP Core向应用服务器2发送403响应 (Forbidden)，告知发送方Tom被禁止发送REFER消息。

步骤905、403响应被返回给Tom，客户端将响应消息提示给Tom。

图9所述的方案中，使用了一种内容类型Content-Type: application/conference-policy+xml包含群组成员列表和群组条件。另一种实 现方案是，注册一种新的内容类型Content-Type，仅用于携带群组条件，这 个群组条件可以与现有的群组列表内容类型Content-Type: application/resource-lists+xml结合使用，也可以单独使用，如在会话过程中 更新群组条件时客户端发送的INVITE消息中就不需要带群组列表，只携带 群组条件即可。

实施例2

Alice邀请了5个同事进行电话会议，并为他们分别设置了会议参与条 件：会议期间，成员A希望订阅其关心的会议群组条件，其发送的 SUBSCRIBE请求的格式为：

SUBSCRIBE建立会话的时候会议服务器分配的会议ConferenceID

   Via:SIP/2.0/TCP memberhost.example.com；branch＝z9hG4bKnashds7

   To：建立会话的时候会议服务器分配的会议ConferenceID

  From:<sip:bill@example.com>；tag＝xfg9

  Call-ID:2010@memberhost.example.com

  CSeq:17766SUBSCRIBE

  Max-Forwards:70

  Event:conference-rules

  Accept:application/conference-rule-info+xml

  Contact:<sip:bill@example.com>

  Expires:600

  Content-Length:0

会议服务器，即SIP应用服务器根据该会议的群组条件判断成员A是 否被允许订阅会议群组条件。如果允许则用NOTIFY返回群组条件，另外当 后续会话群组条件更改后，应用服务器就会发送通知消息。通知消息的格式 为：

NOTIFY sip:bill@example.com SIP/2.0

  Via:SIP/2.0/TCP conference.example.com；branch＝z9hG4bKna998sk

  From:Conference Server<sip:conf34@example.com>；tag＝ffd2

  To:<sip:bill@example.com>；tag＝xfg9

  Call-ID：2010@conference.example.com

  Event:conference-rules

  Subscription-State:active；expires＝599

  Max-Forwards:70

  CSeq:8775NOTIFY

  Contact:<sip:conf34@conference.example.com>

  Content-Type:application/conference-rule-info+xml

  Content-Length:...

  <？xml version＝″1.0″encoding＝″UTF-8″？>

  <conference-rule-info>

    <display-name xml:lang＝″en-us″>Friends</display-name>

   <max-participant-count>10</max-participant-count>

   <subject>My conference</subject>

   <actions>

     <allow-refer-users>TRUE</allow-refer-users>

     <allow-remove-users>FALSE</allow-remove-users>

   </actions>

  </conference-rule-info>

在通知消息中包含内容类型Content-Type: application/conference-rule-info+xml的消息体，其中应用服务器的群组条件 中的公用的群组条件部分可以直接使用，而针对特定群组成员的群组条件并 不是原封不动的放置在通知消息中，而是根据<conditions>对该订阅者满足 的条件获取其对应的动作<actions>，只把其匹配对应的<actions>的内容放置 在通知消息中发给订阅者即可。另外在应用服务器发送给参与者的SIP INVITE消息中如果携带群组条件，也可以采用上述的方法。

本发明实施例不仅可以应用到上述SIP INVITE携带群组条件的场景， 还可以应用发布(SIP Publish)呈现信息等其他场景，使用SIP Publish消息 发布呈现信息到呈现服务器，在Publish消息中带上授权信息(在现有技术 中，只能携带呈现信息，而不能携带授权信息)，授权信息也采用通用规则 (Common Policy)结构构成，与上述的针对特定群组成员的群组条件类似。 这样，呈现服务器就可以根据授权信息对观察者(WATCHER)的呈现信息 订阅进行授权。除了呈现信息(Presence)外，其他的一些事件状态(Event State)的发布也可以在Publish消息中带上授权信息以控制对事件状态信息 的订阅权限。这样就不需要客户端通过其他方式到服务器设置授权信息了， 而是直接在发布的同时就设置了授权信息。

如图10所示，图10为本发明实施例应用在Publish场景中的订阅呈现 信息的方法流程图，其具体步骤为：

步骤1001、呈现体将呈现信息和授权信息用SIP Publish消息发布到呈 现服务器。

其中呈现信息和授权信息使用不同的内容类型Content-Type，如 application/pidf+xml和application/pres-rules+xml。Publish消息与INVITE消 息类似，此处只将授权信息的内容举例如下：

  <？xml version＝″1.0″encoding＝″UTF-8″？>

   <ruleset><rule id＝″1″>

     <conditions>

      <identity><id entity＝″user@example.com″/></identity>

     </conditions>

     <actions><sub-handling>allow</sub-handling></actions>

     <transformations>

      <provide-services>

        <service-uri-scheme>PoC</service-uri-scheme>

        <service-uri-scheme>IM</service-uri-scheme>

      </provide-services>

      <provide-persons><all-persons/></provide-persons>

     </transformations>

   </rule></ruleset>

步骤1002、呈现服务器保存收到的呈现信息和授权信息，并返回200 OK 消息。

如果呈现服务器后续又收到了该呈现体发布的呈现信息，但是没有同时 包含授权信息，则继续可以使用以前保存的授权信息进行鉴权；如果同时包 含了授权信息，则更新以前保存的授权信息。

步骤1003、WATCHER发送SUBSCRIBE消息给呈现服务器，对呈现 信息进行订阅。

步骤1004、接收到SUBSCRIBE消息的呈现服务器，根据上述的授权 信息进行鉴权，鉴权通过后向WATCHER返回200OK消息。

PUBLISH消息发布的事件状态通常都是有有效期的，与事件状态一起 授权信息可以使用相同的有效期。当然PUBLISH消息发布的授权信息也可 以不使用PUBLISH消息里指定的有效期，而是一直有效，直到收到新的授 权信息。

客户端发送的PUBLISH消息中也可以只包含授权信息，这时服务器根 据PUBLISH消息头中的Event字段确定授权信息是针对Request-URI资源 的何种事件状态设置的，如Event字段为presence，则表示针对资源的呈现 信息设置的授权信息。这种情况的授权信息可以一直有效，PUBLISH消息 中有效期Expires头字段对其没有影响。

在本发明实施例中，还提供一种进行多方通信的系统，如图11所示： 其中包括应用服务器和一个以上的客户端，其中，

应用服务器，用于接收客户端发送的携带群组条件的多方通信请求，存 储群组条件，并在建立多方通信后，根据群组条件对多方通信的会话进行集 中控制，以及对客户端发送的多方通信会话变更请求进行处理。

客户端，用于向应用服务器发送携带群组条件的多方通信请求；向应用 服务器发送多方通信会话变更请求。

在本发明实施例中，应用服务器还用于向发起多方通信之外的其他客户 端发送携带针对该客户端的群组条件的多方通信请求，等到客户端回复响应 后，将客户端加入多方通信。

在本发明实施例中，还提供一种进行多方通信的客户端，如图12所示， 包括收发模块，和群组条件生成模块，其中，

群组条件生成模块，用于生成多方通信的群组条件，发送给收发模块；

收发模块，用于将从群组条件生成模块接收到的群组条件包含在多方通 信请求中发送出去。

在客户端中，还包括响应模块，用于从收发模块接收到多方通信请求或 修改多方会话请求后，生成响应消息，通过收发模块发送出去；

收发模块，用于接收多方通信请求或修改多方会话请求，并发送给响应 模块。

在本发明实施例中，还提供一种进行多方通信的服务器，如图13所示， 包括：收发模块、存储群组条件模块以及控制模块，其中，

收发模块，用于接收携带群组条件的多方通信请求后，将携带的群组条 件发送给存储群组条件模块，并将该请求转发给控制模块处理，接收控制模 块发送的响应消息后，转发出去。还可以类似的接收携带更新后群组条件的 修改多方通信请求，将更新后的群组条件发送给存储群组条件模块，将请求 发送给控制模块。

存储群组条件模块，用于从收发模块接收群组条件并存储，在多方通信 过程中提供群组条件给控制模块。

控制模块，用于根据从存储群组条件模块获取的群组条件控制多方通信 的会话。具体的处理从收发模块转发的各种多方通信请求，并根据群组条件 进行处理，然后向收发模块发送响应消息。

以上是对本发明具体实施例的说明，在具体的实施过程中可对本发明实 施例的方法进行适当的改进，以适应具体情况的具体需要。因此可以理解， 根据本发明的具体实施方式只是起示范作用，并不用以限制本发明的保护范 围。