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

专利名称：进行多方通信的方法、系统及装置和发布事件状态的方法
技术领域：
本发明涉及在通信领域中的多方通信技术，特别涉及一种进行多方通信 的方法、系统及装置和发布事件状态的方法。
背景技术：
随着会话初始化协议(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消息体，用以描述参与多方通信的成员的统一 资源冲示i只符(URI， uniform resource identifier)歹'J表。以下以多方通信会话为例进行举例说明。图l为现有技术中采用SIP技术建立会话的方法流程图，包括的网络实 体有会话发起方、应用服务器(可以为IM、 PoC或电话会议服务器等)以 及多个会话参与方，其具体步骤为步骤IOI、会话发起方向应用服务器发起SIP INVITE请求，其中携带 multipart/mixed消息体。步骤102、接收到该请求的应用服务器向会话发起方返回确认消息，即 200 OK响应。步骤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〉和群 组会话主题<subj ect> 。公用的群组条件，与针对特定群组成员的群组条件二者可以选择其一或 并存，在实际应用中， 一般可以并存，其中包括多方通信的群组成员的最 小个数〈min-participant-count〉，小于该个数后多方通信取消；多方通信的群 组成员的最大允许参与人数〈max-participant-count、等于该个数后不允许邀 请新成员加入；多方通信的结束条件〈session-end-criteria〉；是否自动发送群 组信息变更通知<automatic-group-advertisement> ; 会话最长持续时间 <max-duration>、多方通信允许的时间范围〈schedule〉；是否首先将所有多方 通信的群组成员设置为静音〈mute-all-first〉；会话模式，如标识是否立即发 起会话请求，即标识是聊天室群组会话还是即时邀请群组会话。以上可以信 息可以全部或部分的包括在公用的群组条件中。针对特定群组成员的群组条件，与公用的群组条件二者可以选择其一或 并存，该条件采用〈conditions〉-〈actions〉的结构，即满足一定条件时，执 行一定的动作。相关的〈conditions〉可以包括多方通信的群组成员标识〈identity〉、多 方通信的其它群组成员标识<other-identity>或/和多方通信的临时群组成员 〈s-list-member〉等。本发明实施例定义的<actions>包括是否允许群组成员订阅会议状态 <allow-conference-state> 、是否允许群组成员订阅多方通信参与条件 <allow-conference-rule-state>、是否允许群组成员动态邀请其他人参与会话 <allow-invite-users-dynamically>、指示应用服务器是否阻止加入多方通信的 请求〈join-handling〉、是否允许匿名参与多方通信〈allow-anonymity〉、是否 具有高优先级的成员<is-key-participant> 、是否允许群组成员创建多方通信 的子会议〈allow-subconfX是否允许群组成员在多方通信中使用秘密消息、 或/和是否允许将群组中的其他群组成员全部静音(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的SIPINVITE请求发 送给SIP客户端l,其中可以携带或不携带对应于SIP客户端1的群组条件。如果SIP客户端接收到了群组条件，则可以将其内容显示给用户，或者 还可以在后续的通信过程中根据这些群组条件对用户进行控制。例如将群 组条件中的群组会话主题显示在SIP客户端界面上，或禁止用户进行群组条 件中不允许的动作，如创建多方通信的子会议，这样避免客户端发送不被允 许的请求，节约了网络资源和时间。步骤304、 SIP应用服务器将对应于SIP客户端2的SIP INVITE请求发 送给SIP客户端2,其中可以携带或不携带对应于SIP客户端2的群组条件。步骤305、 SIP客户端1接收到步骤303发送的请求后，返回响应，即 200 OK。SIP应用服务器在收到200 OK后回送确认(ACK)响应，建立与SIP客户端1的会话。步骤306、 SIP客户端2接收到步骤304发送的请求后，返回响应，即 200 OK。SIP应用服务器在收到200 0K后回送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请求邀请其加入，然 后向发送"f奮改会话请求的该群组成员返回响应，即返回200 OK。在会话过程中，群组条件可以被更新以更改应用服务器的集中控制行 为。通常只允许会话的发起者如上述的SIP客户端或群组条件中设定的管理 者如上述的SIP客户端1等更新群组条件。会话发起者可以向应用服务器发 送re-INVITE消息，其消息体中携带更新后的群组条件，对现有条件进行替 换或合并。其中可以进一步携带是否替换或合并的指示，应用服务器可以根 据此指示执行群组条件的替换或者合并。在SIP应用服务器执行修改会话请 求时，还可以根据修改会话请求生成对应于本次会话参与成员的re-INVITE 请求，发送给对应的本次会话参与成员，包括本次多方通信会话的发起者。 如更新群组条件后，原先的视频会议现在员生成的群组条件。又如更新的群组条件变为禁止群组参与者A参见，则 应用服务器可以生成断开多方通信会话请求，发送给群组参与者A,禁止其 参与多方通信会话。除了在会话过程中可以用re-INVITE请求的方式来更新群组条件，在发 送SIP INVITE请求后而多方通信会话还尚未建立时，可以用UPDATE消息 来更新群组条件。通过群组条件对多方通信会话进行控制是由SIP应用服务器执行的，在 本发明实施例中，SIP应用服务器可以分为参与功能服务器和控制功能服务 器，会话的修改集中在控制功能服务器上进行的。对于临时群組会话， 一开 始接收SIP INVITE会话建立请求的应用服务器作为控制功能服务器，其他 参与该临时群组会话的应用服务器为参与功能服务器。对于预定义群组会 话，能够根据群组ID获取群组成员的应用服务器为控制功能服务器，其他 参与该预定义群组会话的应用服务器为参与功能服务器。在本发明实施例 中，控制功能服务器主要处理初始的会话请求并维护群组会话条件，执行接 收到的修改会话请求。在本发明实施例中，上述的SIP应用服务器实际上就是控制功能服务 器，参与功能服务器对整个会话来说是透明的，没有参与根据群组条件对会 话的控制。图4为本发明实施例控制功能服务器控制会话的方法流程图，其具体步 骤为步骤401、控制功能服务器接收到SIPINVITE请求。 在临时群组会话中，通常客户端会向一个预定的会场(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邻'J除,保 留剩余的且根据剩余的生成对应于群组成员的SIP INVITE请求。删除这些 URI是为了实现这些群组成员的隐身或者密送的目的。B、 保留公用的群组条件，将针对各个成员的群组条件转化为针对此成 员的群组条件携带在对应于群组成员的SIP INVITE请求中。步骤405、该控制功能服务器将处理后获得的针对每个成员的SIP INVITE请求分别发送给对应的群组成员接收。在发送给各个群组成员的SIP INVITE请求中，可以携带对应于该群组 成员的群组条件，也可以不携带对应于该群组成员的群组条件。如果该请求 携带了群组条件，则群组成员所属的应用服务器(如果不是控制功能服务器 就是参与功能服务器)或群组成员所在的客户端在后续接收到修改会话请求 时可以进行一些过滤处理，这些修改会话请求可以为更改媒体、发送秘密消 息、创造子会议或重新加入会话等，避免客户端发送一些不被允许的请求给 控制功能服务器；而有些则必须到该控制功能服务器进行处理，如邀请群组 成员加入的群组成员个数是否超过了设定的会话参与成员总数等(因为会话参与成员也会邀请成员加入，实时的成员总数只有该控制功能服务器知道)。 如果该请求没有携带群组条件或在会话过程中群组条件发生了变更，则 群组成员所属的应用服务器或群组成员所在的客户端可以通过群组成员订 阅群组条件的过程来获取到群组条件，这个过程后续进行详细描述。步骤406、如果在会话过程中，该控制功能服务器接收到会话变更请求， 如邀请其他成员加入、改变媒体类型等会导致会话信息和状态变更的请求， 该控制功能服务器根据接收到请求中携带的群组成员标识和变更类别查找 到所存储的群组条件。步骤407、该控制功能服务器匹配所存储的群组条件，获取匹配结果。 具体过程为首先应用公用的群组条件，例如本次会话的最大参与人数 为10，如果当前已经有IO个成员参与会话，而其中一个成员使用REFER 请求(SIP消息中的一种)邀请其他成员加入，该控制功能服务器拒绝该请 求。然后，应用针对特定群组成员的群组条件，其中成员标识对应 <conditions>t的条件，变更类别对应〈actions〉中的条件，例如，某个群组 条件中的〈conditions〉/〈dentity〉为此成员的成员标识，或者某个群组条件中 的〈s-list-member〉为此成员的成员标识，则该条件对应该成员；假设该成员 之前是被踢出本次会话的，其〈actions》〈join-handing〉条件为false,即不允 许重新加入，当变更类别为重新加入时，该控制功能服务器拒绝该请求。步骤408、该控制功能服务器根据最终的匹配结果向发送该请求的成员 返回对应的响应，包括接受请求和拒绝请求两种可能。另外参与功能服务器也可以根据群组条件进行会话的控制，假定参与功 能服务器和控制功能服务器为不同的服务器，实际中如果一个参与者与发起 者归属于同一个应用服务器，则该参与者对应的参与功能服务器就是控制功 能服务器。图5为本发明实施例参与功能服务器控制会话的方法流程图，其 具体步骤为步骤501、参与功能服务器接收到SIPINVITE请求。步骤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客户端l修改)来判断是否允许修改。或者 会话参与成员发送的请求。或者此请求被转发到会话发起者处进行授权，应 用服务器根据授权结果向会话参与成员返回对应的响应。步骤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请求，携带预 定义群组标识。步骤80厶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请求邀请新增的成员加入群组会话。如果在更新的群组条 件中设定了禁止某个正在参与会话的成员继续参与会话，则应用服务器可以21向该成员客户端发送禁止(BYE)请求，断开其连接。 举两个具体实施例进行说明。 实施例1Alice邀请了 5个同学进行IM聊天，她希望仅允许这5个同学再邀请一 些朋友参与会话，但是不希望再邀请的这些朋友再次邀请其他人加入聊天， 同时确定总聊天人数不超过10人，所有参与聊天的人员都不允许匿名，不 允许开子会议，不允许传输秘密消息，会议主题为"Merry Xmas and Happy New Year!"。以下是Alice发起SIP INVITE请求的格式<formula>formula see original document page 22</formula><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字4殳指定为Lisa的SIP URI。步骤902、应用服务器2通过SIP/IP Core将该消息路由到控制功能服务 器，即应用服务器1。步骤903、应用服务器1首先匹配公用的群組条件，如检查是否聊天人 数已经达到上限；然后匹配针对Tom的群组条件，确定Conditions中没有 Tom满足的条件，则确定不允许Tom邀请其他人加入会话。步骤卯4、应用服务器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消息中就不需要带群组列表，只携带 群组条件即可。实施例2Alice邀请了 5个同事进行电话会议，并为他们分别设置了会议参与条 件会议期间，成员A希望订阅其关心的会议群组条件，其发送的 SUBSCRIBE请求的格式为SUBSCRIBE建立会话的时候会议服务器分配的会议ConferenceID Via: SIP/2.0/TCP memberhost.example.com;branch-z9hG4bKnashds7 To:建立会话的时候会议服务器分配的会议ConferenceIDFrom: <sip:bill@example.com>;tag=xfg9 Call-ID: 201 O@memberhost.example.com CS叫17766 SUBSCRIBE 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.0Via: SIP/2.0/TCP conference.example.com;branch=z9hG4bKiia998sk From: Conference Server <sip:conf34@example.com>;tag=ffd2 To: <sip:bi 1 l@example.com>;tag=xfg9 Call-ID: 201 O@conference.example.com Event: conference-rules Subscription-State: active;expires=599 Max-Forwards: 70 CSeq: 8775 NOTIFYContact: <sip:conf34@conference.example.com〉 Content-Type: application/conference-mle-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-coimt><subject>My conference</subject><3Ctions><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)呈现信息等其他场景，使用SIPPublish消息 发布呈现信息到呈现服务器，在Publish消息中带上授权信息(在现有技术 中，只能携带呈现信息，而不能携带授权信息)，授权信息也采用通用规则 (Common Policy )结构构成，与上述的针对特定群组成员的群組条件类似。 这样，呈现服务器就可以根据授权信息对观察者(WATCHER)的呈现信息 订阅进行授权。除了呈现信息(Presence)外，其他的一些事件状态(Event State)的发布也可以在Publish消息中带上授权信息以控制对事件状态信息 的订阅权限。这样就不需要客户端通过其他方式到服务器设置授权信息了， 而是直接在发布的同时就设置了授权信息。如图10所示，图lO为本发明实施例应用在Publish场景中的订阅呈现 信息的方法流程图，其具体步骤为步骤1001、呈现体将呈现信息和授权信息用SIP Publish消息发布到呈现服务器。其中呈现信息和授权信息使用不同的内容类型Content-Type,如 application/pidf+xml和application/pres-rules+xml。 Publish消息与INVITE消 息类似，此处只将授权信息的内容举例如下< xml version="1.0" encoding="UTF-8" > <ruleset><mle id=" 1 "> <conditions><identity><id entity="user@example.com'7></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返回200 OK消息。PUBLISH消息发布的事件状态通常都是有有效期的，与事件状态一起授权信息可以使用相同的有效期。当然PUBLISH消息发布的授权信息也可 以不使用PUBLISH消息里指定的有效期，而是一直有效，直到收到新的授 权信息。客户端发送的PUBLISH消息中也可以只包含授权信息，这时服务器根 据PUBLISH消息头中的Event字段确定授权信息是针对R叫uest-URI资源 的何种事件状态设置的，如Event字段为presence,则表示针对资源的呈现 信息设置的授权信息。这种情况的授权信息可以一直有效，PUBLISH消息 中有效期Expires头字段对其没有影响。在本发明实施例中，还提供一种进行多方通信的系统，如图11所示 其中包括应用服务器和一个以上的客户端，其中，应用服务器，用于接收客户端发送的携带群组条件的多方通信请求，存 储群组条件，并在建立多方通信后，根据群组条件对多方通信的会话进行集 中控制，以及对客户端发送的多方通信会话变更请求进行处理。客户端，用于向应用服务器发送携带群组条件的多方通信请求；向应用 服务器发送多方通信会话变更请求。在本发明实施例中，应用服务器还用于向发起多方通信之外的其他客户 端发送携带针对该客户端的群组条件的多方通信请求，等到客户端回复响应 后，将客户端加入多方通信。在本发明实施例中，还提供一种进行多方通信的客户端，如图12所示， 包括收发模块，和群组条件生成模块，其中，群组条件生成模块，用于生成多方通信的群组条件，发送给收发模块；收发模块，用于将从群组条件生成模块接收到的群组条件包含在多方通 信请求中发送出去。在客户端中，还包括响应模块，用于从收发模块接收到多方通信请求或 修改多方会话请求后，生成响应消息，通过收发模块发送出去；收发模块，用于接收多方通信请求或修改多方会话请求，并发送给响应 模块。在本发明实施例中，还提供一种进行多方通信的服务器，如图13所示，包括收发模块、存储群组条件模块以及控制模块，其中，收发模块，用于接收携带群组条件的多方通信请求后，将携带的群组条 件发送给存储群组条件模块，并将该请求转发给控制模块处理，接收控制模 块发送的响应消息后，转发出去。还可以类似的接收携带更新后群组条件的 修改多方通信请求，将更新后的群组条件发送给存储群组条件模块，将请求 发送给控制模块。存储群组条件模块，用于从收发模块接收群组条件并存储，在多方通信 过程中提供群组条件给控制模块。控制模块，用于根据从存储群组条件模块获取的群組条件控制多方通信 的会话。具体的处理从收发模块转发的各种多方通信请求，并根据群组条件 进行处理，然后向收发模块发送响应消息。以上是对本发明具体实施例的说明，在具体的实施过程中可对本发明实 施例的方法进行适当的改进，以适应具体情况的具体需要。因此可以理解， 根据本发明的具体实施方式
只是起示范作用，并不用以限制本发明的保护范 围。
权利要求
1. 一种进行多方通信的方法，其特征在于，该方法包括应用服务器接收到携带本次多方通信的群组条件的多方通信请求后，根据从该请求中获取本次多方通信的群组条件对本次多方通信进行控制。
2、 如权利要求1所述的方法，其特征在于，所述对本次多方通信进行 控制包括应用服务器根据从该请求中获取本次多方通信的群組条件生成针对多 方通信参与方的多方通信请求，分别发送给多方通信参与方；应用服务器根据接收到的多方通信参与方的响应消息将多方通信参与 方加入多方通信。
3、 如权利要求2所述的方法，其特征在于，应用服务器接收到多方通 信i青求后，该方法还包4舌应用服务器建立与发送该多方通信请求的发起方之间的多方通信； 从该请求中获取本次多方通信的群组条件后，存储群组条件。
4、 如权利要求l、 2或3所述的方法，其特征在于，所述的群组条件包 括公用的群组条件和/或针对特定多方通信参与方的群组条件。
5、 如权利要求2所述的方法，其特征在于，所述针对多方通信参与方 的多方通信请求携带的消息体是根据特定多方通信参与方的群组条件设定 的，在建立临时群组的多方通信时，所述群组条件为应用服务器接收到的多 方通信请求中携带的本次多方通信的群组条件；在建立预定义群组的多方通信时，所述群组条件为应用服务器接收到的 多方通信请求中携带的本次多方通信的群组条件和存储在应用服务器的群 组条件合并或替换后生成的。
6、 如权利要求l所述的方法，其特征在于，该方法还包括在多方通信过程中，应用服务器接收携带更新群组条件的修改多方通信 请求，从该请求中获取本次多方通信的群组条件，对多方通信的群组条件进行更新。
7、 如权利要求6所述的方法，其特征在于，所述对多方通信的群组条件进行更新包括对群组条件的替换或者合并；所述的修改多方通信请求中可进一步包含对群组条件进行合并或替换 的指示，根据此指示对群组条件进行更新。
8、 如权力要求6所述的方法，其特征在于，所述的更新群组条件的修 改多方通信请求中，进一步携带新增的群组成员列表；该方法进一步包括应用服务器生成针对新增群组成员的多方通信请 求，分别发送给新增的多方通信参与方。
9、 如权利要求6所述的方法，其特征在于，在所述对本次多方通信的 群组条件进行更新之后，该方法还包括多方通信参与方；或者当本次多方通信的群组条件为禁止至少一个多方通信参与方参与 多方通信，则应用服务器生成断开多方通信请求，发送给所述禁止参与多方 通信的多方通信参与方。
10、 如权利要求9所述的方法，其特征在于，所述针对多方通信参与方 的修改多方通信请求携带的消息体是根椐特定多方通信参与方的群組条件 设定的，在临时群组的多方通信时，所述群组条件为应用服务器接收到的多 方通信请求中携带的本次多方通信的群组条件；在预定义群组的多方通信时，所述群组条件为应用服务器接收到的多方 通信请求中携带的本次多方通信的群组条件和存储在应用服务器的群组条 件合并或替换后生成的。
11、如权利要求5或9所述的方法，其特征在于，在所述分别发送给多 方通信参与方之后，该方法还包括多方通信参与方接收到请求后，将携带在消息体中的群组条件内容进行 显示，或在通信过程中根据携带在消息体中的群组条件对多方通信参与方进行控制。
12、 如权利要求6所述的方法，其特征在于，在所述对本次多方通信的群组条件进行更新之前，该方法还包括多方通信参与方订阅群组条件，应用服务器对多方通信的群组条件进行 更新后，向订阅了群组条件的多方通信参与方发送包含更新的群组条件的通 知消息。
13、 如权利要求l所述的方法，其特征在于，所述应用服务器接收到的多方通信请求中还包括临时群组的成员列表或预定义群组的标识，应用服务 器根据该请求携带的临时群组的成员列表或预定义群组的标识确定多方通 信的参与方，对本次多方通信进行控制为对所确定多方通信的参与方进行控制。
14、 如权利要求13所述的方法，其特征在于，在应用服务器或者XML 文档管理服务器存储有预定义群组标识对应的预先设置的群组条件，所述从该请求中获取本次多方通信的群组条件后，应用服务器将所述的 群组条件与预定义群组标识对应的预先设置的群组条件进行合并或替换。
15、 如权利要求2所述的方法，其特征在于，所述应用服务器包括控制 功能服务器和参与功能服务器，所述针对多方通信参与方的多方通信请求是由控制功能服务器生成的； 所述在分别发送给多方通信参与方之前，还包括将生成针对多方通信参与方的多方通信请求，分别发送给多方通信参与方归属的参与功能服务器，由参与功能服务器转发给多方通信参与方；所述将多方通信参与方加入多方通信是由控制功能服务器控制的； 所述控制功能服务器接收到多方通信参与方的响应消息之前> 还包括 参与功能服务器将接收到的多方通信参与方的响应消息转发给控制功 能服务器。
16、 如权利要求15所述的方法，其特征在于，所述针对多方通信参与 方的多方通信请求中包含群组条件，参与功能服务器将其緩存，用于在多方通信过程中根据该群组条件对多方通信参与方的多方通信请求进行过滤处理。
17、 如权利要求l、 2、 3、 5、 13、 14、 15或16所述的方法，其特征在 于，所述多方通信请求为会话初始化协议SIP中的INVITE请求、或 re-INVITE请求、或UPDATE请求、或REFER请求、或BYE请求。
18、 一种进行多方通信的系统，其特征在于，该系统包括应用服务器和 客户端，其中，应用服务器，用于接收客户端发送的多方通信请求，获取该请求中的群 组条件，且对应于群组条件建立多方通信后，根据群組条件对多方通信会话 进行控制，或对客户端发送的修改多方通信请求进行处理；客户端，用于向应用服务器发送包含群组条件的多方通信请求或修改多 方通信请求。
19、 如权利要求18所述的系统，其特征在于，所述应用服务器包括控 制功能服务器和参与功能服务器，所述的控制功能服务器，用于接收到多方通信请求后，获取该请求中的 群组条件，生成针对客户端的多方通信请求，分别发送给客户端归属的参与 功能服务器；接收到客户端发送的响应消息后对应于群组条件建立多方通 信；所述的参与功能服务器，用于根据接收到的针对客户端的多方通信请求 发送给客户端，接收到客户端的响应消息转发给控制功能服务器；所述的客户端，用于接收针对客户端的多方通信请求，发送响应消息给 所述的参与功能服务器。
20、 如权利要求18所述的系统，其特征在于，所述参与功能服务器将 多方通信请求中包含的群组条件緩存，用于在多方通信过程中根据该群组条件对多方通信参与方的多方通信请求进行过滤处理。
21、 一种进行多方通信的客户端，其特征在于，包括收发模块和群组条 件生成模块，其中，群组条件生成模块，用于生成多方通信的群组条件，发送给收发模块； 收发模块，用于将从群组条件生成模块接收到的群组条件包含在多方通 信请求中发送出去。
22、 如权利要求21所述的客户端，其特征在于，所述客户端还包括响 应模块，用于从收发模块接收到多方通信请求或修改多方会话请求后，生成 响应消息，通过收发模块发送出去；收发模块，用于接收多方通信请求或修改多方会话请求，并发送给响应 模块。
23、 一种进行多方通信的服务器，其特征在于，包括收发模块、存储 群组条件模块以及控制模块，其中，收发模块，用于接收携带群组条件的多方通信请求后，将携带的群组条 件发送给存储群组条件模块，并将该请求转发给控制模块处理，接收控制模 块发送的响应消息后，转发出去；存储群组条件模块，用于从收发模块接收群组条件并存储，在多方通信 过程中提供群组条件给控制模块；控制模块，用于根据从存储群组条件模块获取的群组条件控制多方通信 的会话。
24、 一种发布事件状态的方法，其特征在于，该方法包括应用服务器在接收到携带资源的事件状态和授权信息的发布消息后，根 据所述的授权信息对所述资源的事件状态的订阅权限进行控制。
25、 如权利要求24所述的方法，其特征在于，所述的发布消息为SIP 协议的PUBLISH消息，应用服务器使用所述的授权信息对所述资源的 PUBLISH消息中的Event头字段里指定的事件状态的订阅权限进行控制。
全文摘要
本发明公开了一种进行多方通信的方法、系统及装置和发布事件状态的方法，其中，进行多方通信的方法包括应用服务器接收到携带本次多方通信的群组条件的多方通信请求后，根据从该请求中获取本次多方通信的群组条件对本次多方通信进行控制。本发明实施例提供的方法、系统及装置，可以设置多方通信的群组条件，通过群组条件限制多方通信的参与方。本发明提供的发布事件状态的方法包括应用服务器在接收到携带资源的事件状态和授权信息的发布消息后，根据所述的授权信息对所述资源的事件状态的订阅权限进行控制。该方法能够对事件状态进行订阅限制。
文档编号H04M3/56GK101237336SQ20071000644
公开日2008年8月6日 申请日期2007年2月1日 优先权日2007年2月1日
发明者谦 孙, 扬 招, 田林一 申请人:华为技术有限公司