群組管理

随着用户使用多种终端的需求日益增长，即手机、PDA、PC,而且用户希望在这些设备上都能使用所有服务，就出现了这样的情况：用户希望所有设备都能使用他们的业务数据，于是构造这种数据的需求比以前更加明显了。

解决这个问题的一个办法是使用Web页面。但Web页面会出现两个问题：

1） 用户必须在小屏幕上浏览；

2） 如果利用Web页面解决这个需求，这种数据不能与手机或其他设备上运行的现存的应用集成到一起。

举一个现实生活的例子，来进一步考察这个问题：一个用户想在PC和手机上创建一个"伙伴名单”。因为没有群组管理解决办法，这个用户必须两次创建伙伴名单：一次在PC上，一次在手机上。现在用户进入一个Internet咖啡店，想要使用它的Web消息服务，但他无法使用，因为他的伙伴名单存储在PC本机和手机本机上。如果他能有Web界面使他能够构造伙伴名单并存储在网络上，问题就迎刃而解。但是如果他的手机上的伙伴名单用了设备内嵌的地址本呢？这时需要不同的办法使设备能够把这些数据存储在网络上。那么也可以用相同的办法来建立单独的伙伴名单。于是，不需要用户再构造多个重复的伙伴名单，例如他可以在务 手机地址本上构造一个名单，然后用一种协议将名单上传到网络上。现在当用户登录任何一种设备时，比如PC,该设备就能自动联系网络并取回用手机构造的伙伴名单，而不需要用户干预。

使用这种体系架构的另一个好处是用户能够创建、修改和删除这个名单，并自动进行同步，因为上载和修改这个伙伴名单还有一个内置功能，就是通知其他设备伙伴名单发生了什么改变。

用户已经拥有的服务数据在其他服务中也可以使用，上述的伙伴名单就是一个例子。用户可以于在线状态应用中使用相同的名单——即他的伙伴名单。他还可以用同一个名单创建会议呼叫，伙伴名单代表了参与者名单。

群组管理的另一个创造性的用途是创建访问控制列表(ACL）。用户创建了这个用户列表，用于网络实体在中继转接通信尝试之前进行授权检查。例如，用户Alice创建了ACL,允许Bob和John给自己打电话或者发起蜂窝式按键对讲会话,而阻止Sarah参与其中，网络就会自动拒绝Sarah发起的给Alice的任何通信企图。

8.1群组管理对商业的贡献

群组管理能为已有商业带来贡献，并且本身就创造了商机。运营商和其他服务提供商对于将群组管理与在线状态和即时消息等其他服务集成并进行普及推广方面，担当了主要角色。群组管理服务可以是运营商服务业务量的一部分。目前全球移动通信领域的用户已近10亿户，对于新的消费服务来说是个可赢利的平台。群组管理使用户能存储伙伴名单和与在线状态或其他服务有关的任何其他用户数据，这样提高了客户忠诚度，有线Internet的即时消息服务说明了这一点。用户不愿意只是为了节省几美元，而迁移到另一个订购合同并花时间重新建立群组管理。

提供基本的群组管理服务能给运营商带来相对于没有提供该服务的运营商的竞争优势：通过将群组管理信息绑定到特定运营商服务上，客户能够获得高价值的服务，而没有该信息的其他运营就不能提供这种高价值服务。群组管理为现有服务带来新的业务流量，如会议服务。

8.2 什么是群组管理

群组管理(或称为“数据操作”）是一种服务，允许用户将特定于服务的数据存储在服务提供商的网络上。用户可以随意创建、修改或删除数据。用户需要用于完成服务的任何东西，都可以认为是数据。用户需要它来完成服务。这类数据的例子可以是伙伴名单(在线状态实体列表）和在线状态授权列表。

各种服务，如在线状态、PoC、IM等，都需要支持访问和操纵这些服务的某些数据。这类数据的例子包括：

• 会议访问列表：能够参加会议的参与者列表。在PoC中，这被称为PoC群组。

• 资源列表：可能发出通知的用户列表，这个列表可用于正确地订阅列表中每个资源的状态。这个列表的一个例子就是在线状态实体列表。

• 订阅授权策略：在线状态服务的访问控制策略的实例，说明是否授权给某个特定观察者订阅某个事件集。

服务规定了构成表达上述实例中信息的文档的项目，包括语义和用法。

数据存储在网络上，获得授权的用户可以对其定位、访问、操作(创建、变更、删除）。这使得需要这些数据的服务能够共享和访问他们。

0MA(开放移动联盟）已经采纳将XML文档管理(XDM）作为“群组管理”这个名词的同义词。XDM服务规定了能够被多个服务(0MA称为“使能器”）共享的文档，这类情况包括特定类型的列表——URI列表(全球资源标识，也称为“资源列表”），这对用户是个方便的办法，能够把一群终端用户(例如“朋友"、“家庭”）或其他资源归为一组，期望这种列表能够重用于许多不同的业务。

IETF(因特网工程任务组)定义了XML配置访问协议(XCAP）,第25章也作了简单描述，OMA和3GPP(第三代伙伴工程）已经选择它作为协议来传送、访问、阅读和操作包含数据的XML文档。

8.3 资源列表

SIP(会话初始化协议)特定的事件通知机制(见12.13.1节)允许用户(订阅用户）请求得到资源状态变化的通知。

在许多情况下，用户需要了解状态变化信息的某一特定事件的资源列表是很长的，如果没有某种聚合机制，这就需要用户为每一个资源生成SIPSUBSCRIBE请求，这还将导致SIP NOTIFY请求更快地到达用户终端。由于拥塞控制和带宽限制，让用户终端发送多个SUBSCRIBE请求，为每个资源发送一个请求，是不经济的。图8-1说明了这个问题。

图8-1  在线状态服务订阅流程示例(无RLS时）

为解决这个问题，［Draft-ietf-simple-event-list］描述了一个时间通知扩展，使用户能用一条SUBSCRIBE请求就能订阅一个资源列表。这个列表用URI标识，包括0或多个URL指向原子资源或其他列表。在在线状态服务中，这些资源是在线状态实体。处理列表SUBSCRIBE请求的实体称为资源列表服务器(RLS）。RLS能够为列表中的每个资源生成单独的订阅。这些订阅可以是SIPSUBSCRIBE请求，也可以不是。图8-2说明了解决方案。

图8-2  在线状态服务订阅流程示例(无RLS时）

客户端发送的列表SUBSCRIBE请求包括一个Supported头字段，其中有一个值为''eventlist"的选项标签。如果没有包括这个选项标签并且Request-URI中的URI代表了一个列表，RLS将反馈“421ExtensionRequest”错误响应。

如果接受了订阅，RLS生成NOTIFY请求，携带列表的状态信息。NOTIFY请求包含Require头字段，有一个值为“eventlist"的选项标签。它还包含MIME“multipart/related”类型的正文，正文内部携带了MIME“application/rlmi+xml”类型，带有资源列表的元信息。

8.4  资源列表的XCAP用法

在8.3节讨论了资源列表以及如何获取它们的状态信息，本节将讨论这些列表是如何创建和维护的。

创建列表的解决方法是利用XCAP(参见第25章），并把它作为应用。[Draft-ietf-simple-xcap-usage]定义了XMLschema及其语义，还定义了下列内容：

• 应用用法ID(AUID）——“资源列表”；

• 额外限制——无；

• 命名约定——无；

• 资源独立性——列表由URI表示，如果客户端没有驻留带有URI值的XML元素，XCAP服务器就需要完成这个任务；

• 授权策略——缺省。

资源列表的操作是通过IMS(IP多媒体子系统）体系Ut接口来实现的。

举个例子，Alice使用两个终端：一个在家，一个在办公室。她通过家里的终端创建了伙伴列表，把Bob和Sarah加入伙伴列表。图8-3展示了这个例子。于是就创建了XCAP请求，携带着资源(伙伴）列表，存储在服务器上。

图8-3   资源列表流程示例

XCAP请求如下所示：

PUT     http://xcap.example.eom/services/rusource-lists/users/sip:alice@example.com/

friends.xmlHTTP/1.1

Content-Type:application/resource-lists+xml

<?xmlversion=”1.0"encoding-”UTF-8”?>

<resource-listsxmlns=”um:ietf:params:xml:ns:resource-lists”>

<listname=”friends">

<entry11x1='’sip:bob@example.com”>

<display-name>Bob</display-name>

</entry>

<entryuri=”sip:sarah@example.com”>

<display-name>Sarah㊀/display-name>

</entry>

</list>

</resource-lists>

后来Alice到了办公室，决定把John也加为她的伙伴，她用办公终端完成这件事，修改了原先用家里终端创建的列表。于是创建了XCAP请求，来修改在线状态服务列表服务器上已有的列表。

8.5PoCXML文档管理(XDM）规范

OMA采纳术语"XML文档管理(XDM）”用于群组管理。OMA选择XCAP作为通用协议。XCAP是IETF定义，在本书第25章(XCAP章）有相应的介绍。

下面章节简要描述了针对PoC特定文档的XCAP应用用法。PoCXDM应用用法包括PoC群组和PoC用户访问策略。

8.6 PoCXDM应用用法 

8.6.1 PoC群组

PoC群组是PoC参与者名单，说明谁能加入PoC会话和额外的PoC特定的属性，比如对呼入PoC呼叫请求的自动应答。 

[OMA-TS-PoC_XDM_Vl_0-20050428-C]定义了XMLschema及其语义，它定分义AUID为"org.openmobilealliance.poc-group"。

PoC群组应用的用法包括如下内容：

• 一个URI代表PoC群组标识；

• 群组显示的名字；

• 有一个或多个群组成员(URI）列表；

• 关于是否PoC服务器邀请群组成员加入PoC会话的指示；

• 该群组某个特定PoC会话的最大参与人数；

• 与该群组相关的授权策略。

每个群组成员列表需要包括标识各个单独用户的条目，通过SIP或电化URI,或通过指向外部列表URI的索引。

授权策略(也称为“规则集”）的结构必须符合通用策略，第26章将详细阐述。授权策略的条件包括参与者标识、由外部列表获得的参与者的标识、其他没有在任何规则中体现的标识和检查用户是否是列表成员的条件。

如果条件返回为“true”就可以采取如下动作：允许用户订阅PoC会话状态，允许用户动态邀请参与者加入PoC会话，允许用户加入，阻止用户加入，允许用户启动会话，允许用户匿名，把用户作为关键参与者。

举个例子，Alice想创建一个与Bob、Sarah和John的早期会话，群组就是她的朋友群。她想要她的朋友自行加入，也就是说服务器不会向他们发邀请。加入会话的最大人数不超过4人。这就允许Alice加入更多朋友到列表中，但参与者人数仍然受到限制，因为她不想邀请太多人加入讨论。

Alice想要授权这些人能够加入会议并订阅会话状态，这些人只是成员列表中的一小部分(目前是Bob、Sarah和John）,不允许匿名。XCAP请求内容如下所示，XML文档也作为净荷展示在其中。

PUT http://xcap.example.com/services/org.openmobilealliance.poc-groups/users/sip:alice@example.com/friendsgroup.xmlHTTP/1.1

Content-Type:application/list-service+xml

<?xmlversion=”1.0Hencoding-HUTF-8”?>

<groupxmlns=“um:oma:params:xml:ns:list・service“

xmlns:rl=''uni:ietf:paranis:xml:ns:resource・lists''

xmlns:cr=''um:oma:params:xml:ns:common-policy''>

<list-serviceuri=''sip:myconference@example.com''>

<list>

<rl:entityuri-,sip:bob@example.com,7>

<rl:entityuri=nsip:sarah@example.com*7>

<rl:entityuri=Msip:john@example.com*7>

</list>

<display-namexml:lang=”en-us”>Friends</display-name>

<invite-members>false</invite-members>

<max-participant-count>4</max-participant-count>

<cr:ruleset>

<cr:ruleid=”la”>

<cr:conditions>

<cr:is-list-member/>

</cr:conditions>

<cr:actions>

<allow-conference-state>true</allow-conference-state>

<join-handling>allow</join-handling>

<allow-anonymity>false</allow-anonymity>

</cr:actions>

</cr:ruleset>

</list-service>

</group>

8.6.2PoC用户访问策略

PoC用户访问策略是用户创建的一组规则，用于控制谁能和谁不能发起给他/她的PoC会话。

[OMA-TS-PoC_XDM—Vl_0-20050428-C]定义了XMLSchema及其语义，它定义AUID为”org.openmobilealliance.poc-rules”。

访问策略(也称为“规则集”)的结构必须符合通用策略(第26章将详细阐述）。这种授权策略的条件包括参与者标识，用户接受或拒绝来自该参与者的PoC会话，由外部列表获得的参与者的标识，和其他没有在任何规则中体现的标识。

已满足条件要定义的惟一一个动作是：如何处理邀请。只有三个值中的一个可能出现：通过(pass）、允许(allow）和接受(accept）。“pass”表明PoC服务器利用手工应答流程来处理PoC会话邀请(见6.2.4节），“Accept”表明PoC服务器根据用户的应答模式来接受邀请，“reject”表明PoC服务器拒绝了邀请。

举个例子,Alice创建了用户访问策略，只允许她的朋友邀请她加入PoC会话。她利用先期创建的列表(见8.4节示例）来实现。XCAP请求如下所示，XML文档也作为净荷展示在其中。

PUT http://xcap.example.com/services/org.openmobilealliance.poc-rules/users/sip:alice@example.com/pocrulesHTTP/1.1

Content-Type:application/auth-policy+xml

<?xmlversion=”1.0”encoding-”UTF-8”?>

<rulesetxmlns=”um:oma:params:xml:ns:list-service”

xmlns:poc=”um:ietf:params:xml:ns:poc-rules”>

<ruleid=”f3g44rl”>

<conditions>

<poc:extemal-list>

<poc:anc>/services/resource-lists/users/sip:alice@example.com/

friends/xml

</poc:anc>

</poc:extemal-list>

</conditions>

<actions>

<poc:allow-invite>accept</poc:allow-invite>

</actions>

</rule>

<ruleid=”f3g44rl”>

<conditions>

<other-identity/>

</conditions>

<actions>

<poc:allow-invite>reject</poc:allow-invite>

 </actions>

 </rule>

</ruleset>