Presence（Presence Enhanced Phone Book) 业务以及协议介绍

wenliu

找了个文档，介绍下IMS里的Presence应用，

原文来自 《基于SIMPLE协议的Presence介绍》这篇文章。Presence所涉及的规范还不少，SIP协议也有，OMA的业务规范也有，一个个单独列出来的时候，可能比较枯燥无聊而且也松散，结合Presence应用来看，可能接受更快一点。
目前只引用这篇文章有关业务场景和信令流部分，给初学者一个大概的概念，不对消息内容进行具体解释。有兴趣的可以找这篇文章自己看下，写全了。介绍信令的书都挺多，但是从应用上来描述信令流的文章比较少，这一篇写的不错。

现在因为QQ，Skype这些即时聊天工具的流行，可能会觉得在IMS里搞Presence没什么意思，毕竟推出一个重复的应用，貌似没什么用。但是考虑到QQ这些越来越占运营商流量，而不增收的时候，运营商如果将这块引入，也总算掌握在自己手里的应用产品，而且目前毕竟运营商还控制了用户手机语音这块，用户群和黏度也不低）

“presence”，也作“presence information”，中文一般译为“呈现”，用以传达某一用户通过一组设备进行通信的能力和意愿。拿常见的QQ来举例，QQ用户常用的可选状态有：我在线上、忙碌、马上回来、离开、请勿打扰和显示为脱机。这些状态便称为“presence状态”，它们表征了用户当前处于的某种状态和用户进行通信的意愿。同时，这些状态还反映出与该用户进行通信的能力，比如若用户处于“脱机”状态的话，别的用户便不能用即时消息与之通信。因此，一个最简单的presence过程如下：一个用户（称为watcher）订阅（SUBSCRIBE）他感兴趣的另一用户（presentity）的presence状态，presentity接受订阅请求。以后presentity的状态发生变化之后他会发布（PUBLISH）自己的新状态，这个新状态会通知（NOTIFY）给watcher。（注：watcher、presentity等概念严格上来说指网络中的通信实体，这里为了解释方便将他们进行了扩展，也泛指人）。

目前的IM/presence也主要分为两大阵营：SIP/SIMPLE和JABBER/XMPP。目前介绍SIP/SIMPLE的业务规范

（部分Presence 规范可以参见OMA有关Presence的规范）

SIMPLE符合RFC2778（A Model for Presence and Instant Messageing) 提出的presence模型，其结构图如下：

各实体功能如下：

Ø  Presence Service：接收、存储和分发presence information。PresenceService既可以是一个物理实体上的server，也可以只是presentity和watcher之间的直接通信。 。

Ø  Presentity：用于提供presence information给PresenceService。

Ø  Watcher：向PresenceService请求获取Presentity的presenceinformation或者自身的watcher information。

Ø  Principal：指单个的人、程序或者设备，也可以是人、程序、设备的集合体。对于Presence Service来说，各个Principal是不同的。

Ø  Presence User Agent：为Principal提供手段来操作0个或者多个Presentity，Principal操作Presence User Agent改变Presentity的状态。是Principal和Presentity交互的interface。

Ø  Watcher User Agent：类似Presence User Agent，Principal通过其来操作0个或多个Watcher，Watcher收到Presentity的新状态之后也通过Watcher User Agent呈现给Principal。

Ø  Presence Protocol：定义了Presentity和Presence Service，Watcher和PresenceService之间交换消息的一组标准。

在具体的实现中最常见的是把Presence Service实现为一个Presence Server，PresenceUser Agent和Presentity组合在一起，Watcher和Watcher User Agent组合在一起，由一个终端来同时支持这两种组合体，这样，一个终端就既能订阅别人的也能发布自己的presence information。

一个典型的presence系统需要处理一下一些事件：

Ø  订阅（SUBSCRIBE）和通知（NOTIFY）presenceinformation：

²  RFC 3265“SessionInitiation Protocol (SIP): Specific Event Notification”定义了一套事件通知机制，可应用于presence，作为presence订阅和通知的基本模型，这个机制也适用于下面提到的watcher information。

²  通知presence information的时候需要一种规范的SIP消息体格式以便双方能够识别正确的状态。“draft-ietf-simple-presence-data-model-04”抽象了现实世界中的各种服务、人、设备及其各种信息，并映射到“application/pidf+xml”格式的信息。这种“application/pidf+xml”格式用于SIP消息体中来表示Presentity的各种状态，规范为RFC 3863“PresenceInformation Data Format (PIDF)”。它有一种扩展叫rpidf，定义了更加丰富的状态信息，草案名是“draft-ietf-simple-rpid-08”。

²  SIMPLE中提出了resourcelist的概念，在presence中通常用于好友列表，这样订阅（SUBSCRIBE）的时候只需要订阅好友列表对应的URI，PresenceService会返回所有好友的状态信息，不必一个一个好友单独订阅，节省了网络带宽资源（这对移动通信比较现实）也易于管理。“draft-ietf-simple-event-list-07”解释了如何订阅和通知好友列表，订阅好友列表需要的几种新格式也在该草案中有说明或者引用。订阅好友列表还涉及到好友列表的产生、维护等，这在下面说明。

²  订阅一个用户的presence information会涉及到黑白名单，当Watcher处于Presentity的白名单中时，Presence Service可以直接授权Watcher，允许其订阅，不需要再通知Presentity对应的Principal，让其来验证。而相反，处于黑名单的时候，Presence Service直接拒绝Watcher的订阅请求。添加删除黑白名单可用presence rules来实现，具体草案为“draft-ietf-simple-presence-rules-03”。它也是用XCAP协议传送消息的，XCAP见下面。

Ø  订阅（SUBSCRIBE）和通知（NOTIFY）watcherinformation（下面简称watcherinfo）：

²  watcherinfo记录的是订阅一个Presentity的所有Watcher的集合。（注：下文中会出现两种状态，一种是订阅状态，指的是一个Watcher订阅Presentity的presence状态时订阅动作本身的状态，比如“active”表示订阅经授权Presentity的presence状态发生变化时会通知Watcher，“pending”表示收到订阅并被理解，但尚未授权；还有一种就是刚才提到的presence状态，这种状态指的就是一开始说的表征Presentity通信意愿的状态，如“联机”、“忙碌”等）watcherinfo最典型的应用便是通知用户授权，即Presence Service根据本地策略（一般就是黑白名单）不能决定一个订阅是否被授权时会改变Presentity的watcherinfo，从而通知Presentity有人请求订阅其presence状态，让其授权。具体流程见4.3节。

²  RFC 3857“AWatcher Information Event Template-Package for the Session Initiation Protocol(SIP)”介绍了watcherinfo事件模板包的作用、用法等。

²  和presence一样，wathcerinfo也需要一种标准化的格式来表示这种信息，RFC 3858“AnExtensible Markup Language (XML) Based Format for Watcher Information”定义了一种叫“application/watcherinfo+xml”的格式来满足这一要求

Ø  发布（PUBLISH）presence状态：

   RFC 3903“SessionInitiation Protocol (SIP) Extension for Event State Publication”定义了一种通用的事件状态发布机制，可以应用在presence上发布presence状态信息。

Ø  添加、删除好友以及黑白名单（指的是服务器端存储）：

²  这一系列操作都不是用SIP协议来实现的，而是用基于HTTP的XCAP协议来完成这些功能。XCAP用于客户端将跟应用相关的配置数据存储在服务器端，并用HTTP消息结合具体的消息格式来读、写和修改这些数据。草案“draft-ietf-simple-xcap-07”介绍了此协议。

²  XCAP可应用于presence，用来读、写、修改服务器端的好友列表和黑白名单，它们都称为资源列表（resource list）。“draft-ietf-simple-xcap-list-usage-05”定义了资源列表的用法，介绍了两种描述列表的格式：“application/rls-services+xml”和“application/resource-lists+xml”。

wenliu

下面各个场景都是针对单个用户的（针对多个用户的需要涉及其他的SIP有关resource-list的规范，暂时不引入，以后另外开贴介绍）

订阅单个用户（添加好友）

A想添加B为好友，向B发起一个订阅presence状态的请求。B在线，且接受了A的请求。于是，A成功将B加为好友并且能够观察B的presence状态信息。

wenliu

订阅watcherinfo

情景说明
A在B不在线的时候请求订阅B的状态。后来B登陆，向Presence Server发出订阅其watcherinfo的请求，Presence Server接受请求，通知其最新的watcherinfo状态，由于A的订阅尚未授权，因此会提示B用户鉴权。

（这个过程开起来挺绕，B 上线之后，通过向Presence 服务器订阅自己的watcherinfo，来了解目前有A用户发起了来订阅B用户Presence的请求，B用户需要批准之后，A用户才能看到B用户的Presence）。

wenliu

发布状态信息：
假设A有两位好友：B和C，B一直在线，C不在线。A登陆，向Presence Server发布其presence状态，由于C不在线，Presence Server只通知B A的presence状态发生变化。A经一次状态改变和刷新最后发一个取消发布的PUBLISH退出系统。

（这个比较好理解，就是QQ好友的状态发生变化，你能够实时看到）

wenliu

删除好友：

B是A的好友，A将B删除，B在线。

wenliu

黑白名单：

wenliu

放上我重新整理的一下Presence的文档。更新RFC 文档列表，剔除之前消息流解析时的部分内容，希望先将注意力集中要业务流本身。
业务流中有关xml内容比较重要部分红字标出。


更新部分RFC协议列表。之前网上的资源已经有点陈旧了。
Presence所涉及规范（部分）
列出目前Presence 所涉及的规范部分，具体消息和内容部分在这边不展开。通过第三章的消息场景部分来描述部分常用流程与消息格式。
规范号        协议        用途
RFC 3261        SIP
        SIP根本大纲
RFC 3265        SIP
        定义了基于SIP实现的事件通知机制
RFC3856        SIP        完整阐述了有关呈现业务的事件包
RFC2617        SIP        订阅和发布信息时的鉴权机制
RFC3863        SIP-XML        抽象定义了现实世界中的各种信息
RFC4662        SIP        定义了resource list概念，用与好友列表管理
RFC5025        XCAP        定义了Presence Watcher和Presentity 之间的授权
RFC3857        SIP-XML        介绍了watcherinfo事件模板包的作用、用法等
RFC3858        SIP-XML        定义了watcherinfo，规范了watcherinfo的表达方式
RFC3903        SIP-XML        定义了一种通用的事件状态发布机制，应用在presence上发布状态信息。

RFC4825        XCAP        添加、删除好友以及黑白名单（指的是服务器端存储）
RFC4826        XML        针对资源列表（resource list）的格式定义。

ccc123

感谢分享！！！！