服务---在线状态

在线状态服务(presence)和即时消息(InstantMessaging)正在改变人和组织的通信模式。

在线状态服务将改善消息服务，并且引入了一种新的服务(在线状态服务本身)，可用于许多其他的应用和业务中。在线状态服务将成为所有通信和新的电话功能的核心，其也将成为运营商和服务提供商有利的商业机遇。

在线状态服务是指用户的动态配置，这个配置对于其他人是可见的，可用于表达自身，并共享信息和控制服务。在线状态服务可以看作是其他用户感知的用户本身的状态，和这个用户感知到的其他用户的状态。状态可以包括如下信息：个人或设备状态、位置或上下文、终端能力、优选的联系方式，以及用户喜欢使用哪种通信服务与他人沟通，包括声音、视频、及时消息以及游戏等。

在线状态信息也是私人的，总是和特定的人联系在一起。它显示的是发起通信的人，而不管另一个人是否能够或是否愿意通信。另一方面，当一个人能够并且愿意通信，能够并且愿意跟某人进行某种方式的通信时，在线状态信息才可以用于和其他用户通信。这使得用户能够更有效地控制自己的通信。

共享在线状态信息，能够提高安全性和隐私性。在线状态服务中使用会话初始化协议(SIP),用户能够控制自己的特定的在线状态信息，对于如何使用在线状态信息拥有最终的发言权，包括谁能看见、谁看不见或谁能部分看见在线状态信息的特定部分。

 4.1谁会使用在线状态服务

将来会有许多不同的用户群，使用在线状态信息来达到不同的目的。这些用户群可上至商业公司用户，下到青少年和儿童。在线状态服务尽管看起来更多的是在商业用途中的理性可用性管理，但年轻的消费者总是不断地寻找新方式来表达自己并且构造有趣的、功能丰富的可视标识。成功的在线状态服务将能够满足不同用户群和亚用户群的不同需求。

4.2增强的在线状态服务

众所周知，目前基本的在线状态服务的基本工作理念是“发布——接收”人们的在线状态信息。运营商能够提取各种各样与基础设施相关的在线状态属性，诸如位置、从通信网到终端可达性。对于订购了运营商在线状态信息服务的用户而言，在线状态信息包得到了大大增强和丰富，用户体验得到了极大改善。

支持在线状态信息的新业务将用于专门的应用领域，对于那些希望扩展业务的创新型公司来说，这是一个巨大的机遇，这样的例子包括支持在线状态的呼叫路由及网络游戏业务。此外，在线状态创造了另外一种广告宣传和信息共享通道，并且用户体验良好。

利用在线状态，团队工作将更加高效，无论是否可达，团队成员之间都能共享信息，如成员间能够共享会议地点、下一步计划等信息。

4.3在线状态的商业贡献

在线状态服务能够促进已有的商业，且本身也创造商机。在基本的在线状态用户业务之外，未来还会出现新型增强型在线状态业务。运营商和其他服务提供商在普及在线状态服务中将扮演主要角色。基本的移动在线状态业务能够成为运营商业务集中的一部分，因为其他业务，如新型在线状态业务能够使用基本业务。现在全球移动用户几乎达到10亿个，移动通信领域是新型消费业务的盈利平台。

提供基本在线状态业务的运营商比不能提供的运营商拥有竞争优势：通过把在线状态信息捆绑到运营商特定的业务上，用户能够拥有高价值业务，而其他运营商因为没有在线状态信息而无法提供。在线状态业务为即时消息等现有业务创造新的业务流量。在线状态业务还能最大程度地减少未完成呼叫或者因被叫方遇忙而拒绝的呼叫。

运营商还需要仔细考虑在线状态服务的定价，使人们易于下决心接受在线状态服务，不需要在成本/收益方面考虑太长时间。

4.4什么是在线状态

在线状态（presence）服务本质上包含两个内容：使我的状态为别人可见，也让我可以见到其他人的状态。在线状态信息可以包括：

• 个人和终端是否可达；

• 优选的通信方式;

• 终端能力；

• 当前的行为；

• 位置；

• 当前可用业务。

可以想象，在线状态能够使所有的移动通信更加方便，它不仅仅是即时消息，虽然即时消息已经成为在线状态的主要推动力。即时消息已经成为因特网上主要的几乎实时的交互式通信服务，而在线状态是其重要的优点，因为在开始和一个朋友聊天之前，你能够知道他是否在线。然而在移动环境中，可以想象在线状态信息不仅仅支持即时消息，它还会用于指示是否能够加入任何形式会话，包括语音呼叫、视频和游戏，所有的移动通信都将基于在线状态。

不久的将来，我们就可以使用在线状态所特有的，以及由在线状态所增强的应用和服务。在线状态特有的一个应用性典型例子是：嵌入了在线状态信息的电话簿，使得电话簿成为动态的。动态的在线状态信息（见图4-1）将成为用户在建立通信之前首先看到的信息，这个信息会影响用户选择何种通信方式和通信时间。

图4-1动态在线状态服务

4.5  SIP如何用于在线状态

人们通过创建名为“Presence”的事件包对会话初始化协议（SIP）进行了扩展，以支持在线状态服务。事件包将在12.13.1节中介绍。当订阅这样的事件时，用户将"presence”令牌放入Event消息头中。

为描述再现状态服务的订购者和通告者（notifier）,人们定义了一些概念：

• 在线状态对象（presentity）——在线状态实体，为在线状态服务提供状态信息资源。

• 观察者（watcher）——请求资源（即在线状态实体）的（在线状态）信息实体。

RFC3856为在线状态定义了两个SIP实体：

• 在线状态代理（PA）——能够存储订阅信息，并生成通知。

• 在线状态用户代理（PUA）——为一个在线状态实体处理其在线状态信息并发布这些信息。

如前所述，状态信息通过NOTIFY请求的正文来承载。在这里，状态信息就是在线状态实体的上述各种在线状态。在RFC3863中，这类内容的MIME（多用途因特网邮件扩展）类型被定义为“application/pidf+xml”。在线状态XML（扩展标记语言）文件可以进行扩展，以承载比RFC3863中定义的更多的信息。

在线状态实体使用PUBLISH方法加载在线状态信息，PUBLISH方法在12.13.2节中描述。

4.6 IMS中的在线状态服务体系

用户的在线状态信息可以从IMS（IP多媒体子系统）网络中的多个实体来获得：可以是外部网络中的一个PUA、终端里的PUA或者网络中作为一个实体存在的PUA。在线状态服务器是IMS应用服务器的一个例子。观察者可以和在线状态实体位于同一个归属网络，也可以位于一个外部网络。

图4-2给出了IMS中支持在线状态服务的参考体系。

图4-2  IMS中支持在线状态服务的参考体系

相关实体定义如下：

• 在线状态服务器——管理PUA加载的在线状态信息，并处理在线状态订阅请求。

• 观察者的在线状态代理——标识在线状态实体的目标网络，并解析该实体的地址。

• 线状态实体的在线状态代理——标识分配给某在线状态实体的在线状态服务器。

• 在线状态用户代理（PUA）——集成并提供在线状态信息给服务器。

4.7在线状态实体列表

假设用户（观察者）有许多很多在线状态实体（朋友），这些实体的在线状态信息与自己有关。由于拥塞控制和带宽限制的原因，如果用户终端必须发送多个SUBSCRIBE请求，每个请求发往一个在线状态实体，这是很不经济的。

为解决这个问题，创建了组管理解决方案。8.3节将详细讨论资源列表。状态实体列表是如下类型的资源列表：

• 应用用法ID（AUID）——“资源列表”。

• 额外约束——无。

• 命名惯例无。

• 资源相互依赖性——本列表表示为一个URL如果客户端不填写携带URI值的XML元素，XCAP（XML配置访问协议）服务器需要填写。

• 授权策略——默认。

IMS体系中的Ut接口用于处理资源列表。

4.8设置在线状态授权

不同的观察者可以获得不同级别和不同范围的在线状态信息，这意味着可以授权不同的观察者观看在线状态实体在线状态信息的不同部分。在线状态实体拥有给谁看什么的选择权，在线状态实体可以使用XCAP定义的方案，以许可声明的形式来设置这些授权级别。

［Draft-ietf-geopriv-common-policy］、［Draft-ietf-simple-presence-rules］、［Draft-ietf-simple-common-policy-caps］和［Draft-ietf-simple-pres-policy-caps］中定义了XMLschema及其语义，同时还定义了使用XCAP必须定义的章节。

4.9发布在线状态

通过12.13.2节中定义的SIP扩展可以实现在线状态的发布。PUBLISH请求的Event消息头中携带了“presence”令牌。一次状态发布的默认超时时间是3600s。PUBLISH请求的正文中携带了MIME类型为"application/pidf+xml”的在线状态信息。

4.10观察者信息事件模板包

用户通过一个事件包（在本节中称为“主包"）来订阅并接收特定资源的状态信息。这些用户称为观察者（watcher）。根据观察者信息模板包，用户能够了解观察者以及他们订阅主要数据包的订购状态。观察者信息模板包使用“winfb”令牌来标识。

这个模板包的主要用于在线状态。用户订阅这个模板包，了解谁订阅了他们的在线状态信息以及订阅的状态如何。

订阅了观察者信息的用户收到的信息包含两个重要部分：主包观察者的每个订阅的状态，以及导致从上一个状态迁移到当前状态的事件。

RFC3857中定义的观察者信息包的状态如下：

•初始——还没有为一个订阅分配状态；

•终止——存在一个策略禁止某观察者订阅主事件包；

•激活——存在一个策略授权某观察者订阅主事件包；

•悬挂——对该观察者不存在任何策略；

•等待——类似于悬挂，但是告诉模板包订阅者：一个用户曾经尝试订阅主包，但在一个策略生成之前这个订阅就超时了。

4.11在线状态服务操作的信令流程举例

4.11.1成功的在线状态订阅

图4-3给出了一个观察者成功订阅在线状态信息的流程实例，观察者位于他的归属网络，而在线状态实体位于另外一个不同的网络。这个流程展示了从SUBSCRIBE请求直到对应的第一个NOTIFY请求。

4.11.2成功的在线状态信息发布

图4-4给出了一个在线状态实体成功发布在线状态信息的流程实例。本例中用户设备（UE）作为PUA,—般这会导致PS（分组交换）域对观察者生成通知。

4.11.3订阅资源列表

图4-5给出了一个观察者订阅一个资源列表的在线状态信息的流程实例，该列表在之前已经产生（可能是利用XCAP），列表中的在线状态实体（资源）用SIP URI来指代。这个流程中，在接收到SUBSCRIBE请求后，紧接着发出NOTIFY请求。如果资源列表服务器（RLS）没有保存列表中资源的在线状态信息，则NOTIFY请求就包含一个空的正文。

图4.3成功的在线状态订阅

图4-4  成功的发布

图4-5  订阅一个资源列表

4.11.4订阅观察者信息

图4-6显示了当用户订阅要接收观察者状态的变化情况时，信息如何在PUA和PS域之间流动。这些消息的传输路径和PUBLISH请求相同。该流程展示了在一个订阅请求成功后，紧接着发出了通知。图4-7总结了在线状态服务器、观察者和在线状态实体之间的交互过程。

图4-6    订阅观察者信息

图4.7在线状态服务器、观察者和在线状态实体之间的交互