中财网携程网机票报销凭证:1.概述 2.基于SIMPLE协议的presence体系结构 - xtdxlx126的专栏...
来源：百度文库 编辑：中财网 时间：2024/05/09 16:10:47
1.概述 2.基于SIMPLE协议的presence体系结构 收藏
1.概述
“presence”，也作“presence information”，中文一般译为“呈现”，用以传达某一用户通过一组设备进行通信的能力和意愿。拿常见的MSN Messenger来举例，MSN v7.5为用户提供的可选状态有：联机、忙碌、马上回来、离开、接听电话、外出就餐和显示为脱机。这些状态便称为“presence状态”，它们表征了用户当前处于的某种状态和用户进行通信的意愿。同时，这些状态还反映出与该用户进行通信的能力，比如若用户处于“脱机”状态的话，别的用户便不能用即时消息与之通信。因此，一个最简单的presence过程如下：一个用户（称为watcher）订阅（SUBSCRIBE）他感兴趣的另一用户（presentity）的presence状态，presentity接受订阅请求。以后presentity的状态发生变化之后他会发布（PUBLISH）自己的新状态，这个新状态会通知（NOTIFY）给watcher。（注：watcher、presentity等概念严格上来说指网络中的通信实体，这里为了解释方便将他们进行了扩展，也泛指人）
随着市场对presence和IM（即时通信）的需求日益增大，各种各样的实现也如雨后春笋般冒了出来。但是目前市场上的大部分实现一般都采用私有协议，相互之间不兼容，呈现功能实现的也不完整。为了对presence和IM规范化，IETF在1998年成立了IMPP（Instant Message and Presence Protocol）工作组，希望设计出健壮、安全和灵活的呈现/即时消息协议。IMPP主要定义必要的协议和数据格式，用来构建一个具有空间接收、发布能力的即时信息系统。现在已经提出了各种不同的协议草案或建议，如：SIMPLE、XMPP、PRIM和APEX等。其中，最有实力的是前两个标准，目前的IM/presence也主要分为两大阵营：SIP/SIMPLE和JABBER/XMPP。本文主要介绍基于SIMPLE的presence。
2.基于SIMPLE协议的presence体系结构
SIMPLE规范是在2001年2月由IETF SIMPLE工作组正式提出的，全称为 SIP Instant Messaging and Presence Leveraging Extensions (针对即时消息和呈现业务的利用扩展的会话初始化协议)，是SIP协议针对IM/presence的扩展。
SIMPLE是目前为止制定的较为完善的一个规范，微软和IBM都致力于在它们的即时通讯系统中实现这个协议。
SIMPLE符合RFC2778提出的presence模型，其结构图如下：
Figure 1 presence model
注：上面的实体都是功能实体，与实际实现中的物理实体往往有差别。
各实体功能如下：
Ø Presence Service：接收、存储和分发presence information。Presence Service既可以是一个物理实体上的server，也可以只是presentity和watcher之间的直接通信。在具体实现中前者比较常见，后者是P2P的模式。
Ø Presentity：用于提供presence information给Presence Service。
Ø Watcher：向Presence Service请求获取Presentity的presence information或者自身的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和Presence Service之间交换消息的一组标准。
在具体的实现中最常见的是把Presence Service实现为一个Presence Server，Presence User Agent和Presentity组合在一起，Watcher和Watcher User Agent组合在一起，由一个终端来同时支持这两种组合体，这样，一个终端就既能订阅别人的也能发布自己的presence information。
3.SIMPLE规范阅读指南
2008-02-20 18:24
3.SIMPLE规范阅读指南
IETF的协议规范具有模块化的特点，每一个规范解决一个具体的问题，要构造一个特定功能的系统需要选取适当的规范组合起来共同配合完成功能，SIMPLE的所有规范当然也不例外。IETF针对一个特定的需求往往会先提出一个定义该需求的整体模型，然后由后续的各个规范来详细解决其中的各个子功能（当然，在定义各个子功能的时候也可能会提出针对该类型功能的模型，然后再细化解决）。
SIMPLE是SIP的扩展，因此阅读SIMPLE规范之前要对SIP有所了解，SIP入门可以看《SIP揭密》，具体的规范是RFC 3261“SIP: Session Initiation Protocol”。
RFC 2778“A Model for Presence and Instant Messaging”定义了一个通用的IM/presence模型，RFC 2779“Instant Messaging / Presence Protocol Requirements”提出IM/presence的需求。
对于presence，RFC 3856 “A Presence Event Package for the Session Initiation Protocol (SIP)”整体阐述了presence事件包。
每次订阅和发布信息的时候一般都需要鉴权（authentication），比较常见的是采用Digest机制，规范为RFC 2617 “HTTP Authentication: Basic and Digest Access Authentication (for SIP)”。
一个典型的presence系统需要处理一下一些事件：
Ø 订阅（SUBSCRIBE）和通知（NOTIFY）presence information：
² RFC 3265“Session Initiation 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“Presence Information Data Format (PIDF)”。它有一种扩展叫rpidf，定义了更加丰富的状态信息，草案名是“draft-ietf-simple-rpid-08”。
² SIMPLE中提出了resource list的概念，在presence中通常用于好友列表，这样订阅（SUBSCRIBE）的时候只需要订阅好友列表对应的URI，Presence Service会返回所有好友的状态信息，不必一个一个好友单独订阅，节省了网络带宽资源（这对移动通信比较现实）也易于管理。“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）watcher information（下面简称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“A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)”介绍了watcherinfo事件模板包的作用、用法等。
² 和presence一样，wathcerinfo也需要一种标准化的格式来表示这种信息，RFC 3858“An Extensible Markup Language (XML) Based Format for Watcher Information”定义了一种叫“application/watcherinfo+xml”的格式来满足这一要求
Ø 发布（PUBLISH）presence状态：
RFC 3903“Session Initiation 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”。
4.典型消息流程
情景设定：
假设本presence系统的域名是“cintel.net.cn”,系统中有一下几个实体：
Ø Presence Server：系统中的presence服务器。负责接收和处理所辖域内用户的订阅、发布状态请求；通知用户其订阅的状态信息发生改变；处理添加和删除好友；处理添加和删除黑白名单；管理维护所辖域内用户数据等。其SIP-URI为“sip:ps.cintel.net.cn”，FQDN为“ps.cintel.net.cn”
注：这里假设此Presence Server是整个presence系统的authority，也就是说本系统内所有presence用户的数据全由此服务器来管理。本服务器收到一个订阅本系统内用户状态的请求时，不需要向别的服务器进行后端订阅（back-end subscription）。测试环境中这已经满足要求，如果以后再有需求可以增加对跨系统后端订阅的支持。
Ø A：代表用户A。在网络中是一个终端（可以是软终端或者硬终端），集watcher和presentity实体功能于一身。用于向Presence Server发送订阅（SUBSCRIBE）别的用户状态的请求；自己状态发生变化时向Presence Server发布（PUBLISH）新的状态；接收和处理Presence Server发来的状态通知（NOTIFY）；利用XCAP协议发送和接收添加删除好友、黑白名单的请求和响应等。其在系统中的AOR为“sip:A@ps.cintel.net.cn”，FQDN为“a.cintel.net.cn”。
Ø B：与A类似，AOR为“sip:B@ps.cintel.net.cn”，FQDN为“b.cintel.net.cn”。
Ø C：与A类似，AOR为“sip:C@ps.cintel.net.cn”，FQDN为“c.cintel.net.cn”。
Ø 由于pidf只定义了基本的状态，如basic元素中的“open”和“close”两种状态（前者表示当前的通信状态可用（最常见的就是表示可以发送即时消息），后者表示当前的通信状态不可用），详细一点的状态信息比如“busy”、“away”等没有明确规定。要表示这种状态由具体实现决定，一般都是进行扩展，如teltel是在note元素中表达这种信息。另外，rpidf对pidf进行了扩展，提供丰富的各种信息，具体见参考[10]。此文档中在PIDF的“status”元素下扩展“im”元素，来表示具体的状态（假设有“联机”、“忙碌”、“离开”和“显示为脱机”四种状态，对应的im元素值分别为“online”、“busy”、“away”和“offline”），前面三种属于“status/basic”值为“open”的情况，后一种属于值为“close”的情况。
注：为了便于说明，下面流程中A、B、C三者的关系不是固定的，在具体的情景中有特定的关系
4.1 订阅好友列表
4.1.1情景说明
A拥有且仅拥有B和C两位好友，也就是说A有权订阅B和C的状态信息。终端A启动，向Presence Server发送订阅其好友列表的请求（好友列表URI格式为“sip:username-list@ps.cintel.net.cn”）。假设B一开始处于不在线状态，C至始至终处于“open”状态。Presence Server经过验证将B和C的状态信息通知A。一段时间后B登陆，其状态发生了变化，于是B向Presence Server发布其新状态。Presence Server处理之后将B的新状态通知A，A处理之后会正确显示出B的新状态。在每次订阅超时之前A会重新发送一个订阅请求刷新他的订阅。A退出，向Presence Server发送取消订阅的请求，Presence Server接收并发送最后一次状态通知。
4.1.2 SIP消息流程图
Figure 2 subscribe buddy list
4.1.3 消息流说明
1. A启动，向Presence Server发送订阅其好友列表状态的请求。由于这次订阅的是好友列表，不是单个用户的状态，需要通信双方支持消息体格式：multipart/related、application/rlmi+xml和application/pidf+xml，在Accept头字段中指明A终端支持这三种消息体。此外，好友列表还要求双方支持“eventlist”的扩展，这也要在Supported头字段中指明。此消息中还必须加入头字段Event，表明此次订阅的事件包（event package）类型，在这里其值应该是“presence”。Expires头字段是可选的，用于终端指定一次订阅请求所希望维持的有效时间，单位为秒。如果在订阅请求中没有指定，那么表明终端希望服务器端来指定一个有效时间。
Presence Server收到订阅请求之后，会对A进行验证（Authentication），一般比较常见的是采用Digest机制（见参考[21]）。通过验证之后会对请求消息的关键部分进行检查（见参考[22]、[23]），并根据Presence Server所维护的presence rules（定义了每一个用户对别的用户订阅请求的授权情况，通常所说的“黑白名单”就是基于它实现的，见参考[13]）对A进行授权。由于我们的情景中已经假设B和C都是A的好友，即A处于B和C定义的presence rules中的“白名单”中，A可以直接从Presence Server处获取B和C的状态（这属于local policy的情形）。脱离这个情景，如果A订阅的好友列表中有用户将其列在黑名单中（即“presence authorization document”中“actions/sub-handing”元素值为“block”，见参考[13]），那么Presence Server将会在后续的NOTIFY请求中通知A针对该用户的订阅状态处于“terminated; reason=rejected”；如果A订阅的好友列表中有用户的订阅状态尚不能确定（即“presence authorization document”中“actions/sub-handing”元素值为“confirm”，见参考[13]或者该document中没有A的信息），那么Presence Server无法在立即返回的NOTIFY中通知A该用户的presence状态，Presence Server会代替A向该用户发起订阅请求，这后续过程会涉及到用户人为干涉验证等，这会在“4.2 订阅单个用户”中详述。
M1消息如下：
SUBSCRIBE sip:A-list@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP a.cintel.net.cn; branch=z9hG4bKwYb6QREiCL
Max-Forwards: 70
To: < sip:A-list@ps.cintel.net.cn >
From:
Call-ID: cdB34qLToC@a.cintel.net.cn
CSeq: 1 SUBSCRIBE
Contact:
Event: presence
Expires: 3600
Supported: eventlist
Accept: application/pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Content-Length: 0
2. 由于情景假设，Presence Server可以根据本地策略（local policy）直接获取A好友的presence状态，因此其向A发送“200 OK”，表明此次订阅已经得到验证和授权，订阅操作成功。
在此200响应中Presence Server会加入一个Expires头字段，如果前面的SUBSCRIBE中没有指定Expires，那么Presence Server分配一个缺省值，如果已经指定，那么会根据自己的策略选取一个适当的值（见参考[23]），Presence Server可以缩短SUBSCRIBE中指定的时间，但是绝对不能延长这个时间。这里假设Presence Server将此时间缩短为3200秒。此外，由于这个是订阅好友列表的请求，Presence Server还会增加一个Require头字段，值为“eventlist”，表明Presence Server要求终端A支持eventlist扩展。
M2消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP a.cintel.net.cn; branch=z9hG4bKwYb6QREiCL
To: < sip:A-list@ps.cintel.net.cn >;tag=zpNctbZq
From:
Call-ID: cdB34qLToC@a.cintel.net.cn
CSeq: 1 SUBSCRIBE
Contact:
Expires: 3200
Require: eventlist
Content-Length: 0
4.典型消息流程 3
2008-02-20 18:27
3. 根据RFC 3265 [22]的要求，Presence Server在返回一个针对SUBSCRIBE的200 OK响应之后会立即给A发送NOTIFY通知其已经知道的好友的状态。在这个NOTIFY消息中Event和Require头字段同样需要，此外，还要加入一个Subscription-State的头字段（其包含的订阅状态的具体含义见参考[22] 3.2.2章），它包含一个expires参数，指明这次订阅还剩下的有效时间，如果为0，表示服务器端想终止此次订阅。这里由于是立即返回的NOTIFY，因此值为3200。这个NOTIFY请求包含的消息体类型是“multipart/related”，其又包含两中类型的格式：application/rlmi+xml用来描述整个好友列表，application/pidf+xml描述每个好友的具体presence状态信息。在这里，B不在线，因此状态为“offline”，C在线，处于“online”状态。（注pidf可以经扩展支持更加丰富的各种状态信息）
M3消息如下：
NOTIFY sip:a.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKMgRenTETmm
Max-Forwards: 70
From:
To:
Call-ID: cdB34qLToC@a.cintel.net.cn
CSeq: 5768 NOTIFY
Contact:
Event: presence
Subscription-State: active;expires=3200
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";
start="
boundary="50UBfW7LSCVLtggUPe5z"
Content-Length: 1560
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/rlmi+xml;charset="UTF-8"
uri="sip:A-list@ps.cintel.net.cn" version="1" fullState="true"> cid="B@ps.cintel.net.cn"/> cid="C@ps.cintel.net.cn"/>
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/pidf+xml;charset="UTF-8"
entity="sip:B@ps.cintel.net.cn">
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/pidf+xml;charset="UTF-8"
entity="sip:C@ps.cintel.net.cn">
--50UBfW7LSCVLtggUPe5z--
4.典型消息流程 4
2008-02-20 18:27
4. A收到NOTIFY之后进行处理，将B和C的状态正确显示出来，并返回“200 OK”完成NOTIFY事务。
M4消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKMgRenTETmm
From:
To:
Call-ID: cdB34qLToC@a.cintel.net.cn
CSeq: 5768 NOTIFY
Contact:
Content-Length: 0
5. 一段时间后B登陆，B向Presence Server发布其新的状态信息。类似于SUBSCRIBE方法，PUBLISH（PUBLISH不创建dialog）也要头字段Expires和Event。比较特殊的是PUBLISH中不包含Contact头字段（见参考[8]）。
M5消息如下：
PUBLISH sip:B@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP b.cintel.net.cn;branch=z9hG4bK652hsge
Max-Forwards: 70
To:
From:
Call-ID: 81818181@b.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3600
Event: presence
Content-Type: application/pidf+xml
Content-Length: 224
entity="sip:B@ps.cintel.net.cn">
6. Presence Server收到PUBLISH请求之后将B的新状态保存在数据库中，并返回200响应。类似于SUBSCRIBE，也包含一个Expires头字段，用法也一样。另外，此200响应中还应该有一个SIP-ETag头字段，用来标识和验证B的下一次PUBLISH（见参考[8]、[23]）。
M6消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP b.cintel.net.cn;branch=z9hG4bK652hsge
To:
From:
Call-ID: 81818181@b.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3200
SIP-ETag: dx200xyz
Content-Length: 0
4.典型消息流程 4
2008-02-20 18:27
4. A收到NOTIFY之后进行处理，将B和C的状态正确显示出来，并返回“200 OK”完成NOTIFY事务。
M4消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKMgRenTETmm
From:
To:
Call-ID: cdB34qLToC@a.cintel.net.cn
CSeq: 5768 NOTIFY
Contact:
Content-Length: 0
5. 一段时间后B登陆，B向Presence Server发布其新的状态信息。类似于SUBSCRIBE方法，PUBLISH（PUBLISH不创建dialog）也要头字段Expires和Event。比较特殊的是PUBLISH中不包含Contact头字段（见参考[8]）。
M5消息如下：
PUBLISH sip:B@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP b.cintel.net.cn;branch=z9hG4bK652hsge
Max-Forwards: 70
To:
From:
Call-ID: 81818181@b.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3600
Event: presence
Content-Type: application/pidf+xml
Content-Length: 224
entity="sip:B@ps.cintel.net.cn">
6. Presence Server收到PUBLISH请求之后将B的新状态保存在数据库中，并返回200响应。类似于SUBSCRIBE，也包含一个Expires头字段，用法也一样。另外，此200响应中还应该有一个SIP-ETag头字段，用来标识和验证B的下一次PUBLISH（见参考[8]、[23]）。
M6消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP b.cintel.net.cn;branch=z9hG4bK652hsge
To:
From:
Call-ID: 81818181@b.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3200
SIP-ETag: dx200xyz
Content-Length: 0
11. Presence Server立即返回NOTIFY通知A当前其全部好友的presence状态。
M11消息如下：
NOTIFY sip:a.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKMgRenTETmo
Max-Forwards: 70
From:
To:
Call-ID: cdB34qLToC@a.cintel.net.cn
CSeq: 5770 NOTIFY
Contact:
Event: presence
Subscription-State: active;expires=3200
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";
start="
boundary="70UBfW7LSCVLtggUPe5z"
Content-Length: 1560
--70UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/rlmi+xml;charset="UTF-8"
uri="sip:A-list@ps.cintel.net.cn" version="3" fullState="true"> cid="B@ps.cintel.net.cn"/> cid="C@ps.cintel.net.cn"/>
--70UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/pidf+xml;charset="UTF-8"
entity="sip:B@ps.cintel.net.cn">
--70UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/pidf+xml;charset="UTF-8"
entity="sip:C@ps.cintel.net.cn">
--70UBfW7LSCVLtggUPe5z--
4.典型消息流程 7
2008-02-20 18:30
12. A收到NOTIFY消息之后刷新所有好友的presence状态并返回200响应完成NOTIFY事务。
M12消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKMgRenTETmo
From:
To:
Call-ID: cdB34qLToC@a.cintel.net.cn
CSeq: 5770 NOTIFY
Contact:
Content-Length: 0
13. 后来，A终端退出，会触发一个取消订阅的请求，在SIMPLE中这是通过置Expires头字段值为0来完成的。此SUBSCRIBE仍属于第一个创建的对话（dialog）。
M13消息如下：
SUBSCRIBE sip:A-list@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP a.cintel.net.cn; branch=z9hG4bKwYb6QREiCN
Max-Forwards: 70
To: < sip:A-list@ps.cintel.net.cn >;tag=zpNctbZq
From:
Call-ID: cdB34qLToC@a.cintel.net.cn
CSeq: 3 SUBSCRIBE
Contact:
Event: presence
Expires: 0
Supported: eventlist
Accept: application/pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Content-Length: 0
14. Presence Server接受取消订阅的请求，向A返回Expires值为0的200响应。
M14消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP a.cintel.net.cn; branch=z9hG4bKwYb6QREiCN
To: < sip:A-list@ps.cintel.net.cn >;tag=zpNctbZq
From:
Call-ID: cdB34qLToC@a.cintel.net.cn
CSeq: 3 SUBSCRIBE
Contact:
Expires: 0
Require: eventlist
Content-Length: 0
15. Presence Server会给A发最后一次NOTIFY，通知其所有好友的状态，并且Subscription-State的expires参数值设为0，表示订阅有效时间已经结束，这是最后一次presence状态发布。
M15消息如下：
NOTIFY sip:a.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKMgRenTETmp
Max-Forwards: 70
From:
To:
Call-ID: cdB34qLToC@a.cintel.net.cn
CSeq: 5771 NOTIFY
Contact:
Event: presence
Subscription-State: active;expires=0
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";
start="
boundary="80UBfW7LSCVLtggUPe5z"
Content-Length: 1560
--80UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/rlmi+xml;charset="UTF-8"
uri="sip:A-list@ps.cintel.net.cn" version="4" fullState="true"> cid="B@ps.cintel.net.cn"/> cid="C@ps.cintel.net.cn"/>
--80UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/pidf+xml;charset="UTF-8"
entity="sip:B@ps.cintel.net.cn">
--80UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/pidf+xml;charset="UTF-8"
entity="sip:C@ps.cintel.net.cn">
--80UBfW7LSCVLtggUPe5z--
16. A收到最后一个NOTIFY之后返回200完成NOTIFY事务。
M16消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKMgRenTETmp
From:
To:
Call-ID: cdB34qLToC@a.cintel.net.cn
CSeq: 5771 NOTIFY
Contact:
Content-Length: 0
4.2 订阅单个用户（添加好友）1
2008-02-20 18:32
4.2.1 情景说明
A想添加B为好友，向B发起一个订阅presence状态的请求。B在线，且接受了A的请求。于是，A成功将B加为好友并且能够观察B的presence状态信息。
4.2.2 消息流程图
Figure 3 subscribe single user
4.2.3 消息流说明
注：上图中M开头的是SIP消息，H开头的是HTTP消息。验证（authentication）没有包含在内。
假设之前代表A的好友列表的resource-list的document已经和维护所有列表资源的rls-resources的document已经关联好（这种关联与下面的操作类似，也是通过PUT方法来完成的，详细的流程请见参考[16]）。存储在服务器端的这两个document内容如下（XCAP root为“http://ps.cintel.net.cn”）：
Content of resource-list document:
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
Content of rls-resources document:
xmlns:rl="urn:ietf:params:xml:ns:resource-lists" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> resource-lists/list%5b@name=%22buddies%22%5d
注：上面的内容虽然表示的时候用的是XML格式，并且术语上还说存在document中，但是这个document是广义的，不仅仅指一个文本文档，事实上，一般来说这种信息都是存储在数据库中的，这就需要一个将XML数据映射到数据库数据的过程，详细的映射方法见参考[24]。
1. A想添加B为好友，将B添加到其本地好友列表中，同时产生一个SUBSCRIBE消息发送给Presence Server。此外，A还会向Presence Server发送一个基于XCAP协议的HTTP消息PUT，用来添加B到服务器端的好友列表中以保持两边的列表信息同步。
H1消息如下：
PUT
/resource-lists/users/A/buddies.xml
/~~/resource-lists/list%5b@name=%22buddies%22%5d/entry HTTP/1.1
Content-Type:application/xcap-el+xml
Host: ps.cintel.net.cn
删除B并返回200之后A的终端再正式在本地好友列表中删除B。
4.2 订阅单个用户（添加好友） 2
2008-02-20 18:34
2. Presence Server收到“H1: PUT”之后，将B添加到A的好友列表中。收到“M1: SUBSCRIBE”后，检查B的presence rules，得知对来自A的订阅的本地策略未知，于是在A的好友列表中将B的订阅状态设置为“pending”，并且返回“202 Accepted”，表示收到订阅请求并被理解，但是还没得到授权。
3. Presence Server向A发送NOTIFY通知其对B的订阅请求处于“pending”状态。并且，在B的watcherinfo信息中添加一条A的记录，状态为“pending”，表示A请求订阅B的presence状态。watcherinfo状态一旦发生变化之后Presence Server会向B发送NOTIFY消息通知，消息体类型为“application/watcherinfo+xml”，典型的消息体如下：
version="1" state="partial"> status="pending">sip:A@ps.cintel.net.cn
4.2 订阅单个用户（添加好友）3
2008-02-20 18:35
4. B的终端收到“M4: NOTIFY”之后立即返回200完成NOTIFY事务。同时向B用户弹出提示：A请求加好友。在这里，终端可以给B用户提供两种选择：仅仅接受A的请求或者接受订阅请求的同时还将A加为好友。如果B选择前者，那么B终端只需向Presence Server发送一个添加A到B的白名单中的HTTP请求PUT（这种消息体格式为“application/auth-policy+xml”，见参考[13]）。如果B用户选择后者，B终端在本地好友列表中添加A用户，并且除了向Presence Server发送加白名单的PUT请求，还需要发送一个将A添加为B好友的PUT请求和一个订阅A的presence状态的SUBSCRIBE请求（这次B加A好友的过程与A加B一样，只是方向相反）。这里不管B用户选择前者还是后者都不再描述与前面过程类似的消息，只描述A加B好友的那部分后续消息。
H3消息如下：
PUT
/pres-rules/users/B/presrules.xml/~~/rule-set/
rule?xmlns(cr=%22urn:ietf:params:xml:ns:common-policy%22) HTTP/1.1
Content-Type:application/xcap-el+xml
Host: ps.cintel.net.cn
5. Presence Server收到“H3: PUT”之后，返回一个200响应，并且将A添加到B的白名单中，将A的好友列表中B的订阅状态改为“active”。然后查询B的当前presence状态，构造NOTIFY消息通知A。
6. A收到响应之后返回200完成NOTIFY事务，并将B的presence状态显示出来。
说明：
Ø 如果A加B好友的时候B不在线，消息流程图中M3之前（含M3）的消息不变，只是Presence Server在B的watcherinfo中添加A的记录之后不会立即给B发送NOTIFY，而是等到B登陆之后发送，此过程会包含在4.3节中描述。
Ø 如果B收到“M4: NOTIFY”之后不接受A的订阅请求，随即返回的SIP消息还是200（事实上这个200响应是在B用户做出决定之前终端就自动发的，它仅表明NOTIFY消息被接受，立即返回200是为了维持NOTIFY事务，因为这种事务不能时间过长）。但是在“H3: PUT”中不是添加到白名单的信息，而是添加到灰名单。Presence Server收到这个请求后如何处理由实现决定，可以构造一个带“Subscription-State: terminated; reason=rejected”头字段的NOTIFY消息给A，A终端收到这个消息后将B在本地好友列表置于临时删除状态，并且向A发送一个HTTP的DELETE请求，用以删除Presence Server端A好友列表中的B记录。Presence Server收到请求确实删除B并返回200之后A的终端再正式在本地好友列表中删除B.
4.3 订阅watcherinfo
2008-02-20 18:35
4.3 订阅watcherinfo
4.3.1 情景说明
假设C用户已被授权订阅了B的presence状态，A在B不在线的时候请求订阅B的状态。后来B登陆，向Presence Server发出订阅其watcherinfo的请求，Presence Server接受请求，通知其最新的watcherinfo状态，由于A的订阅尚未授权，因此会提示B用户鉴权。
4.3.2 SIP消息流程图
Figure 4 subscribe watcherinfo
4.3.3 消息流说明
Presence系统对watcherinfo的处理和presence类似，只是事件包（event package）变为*.winfo（如果是针对presence的watcherinfo，那么就是presence.winfo，见参考[4]）。当然，响应的消息体也会不同（见参考[5]）。
1. B终端启动，向Presence Server发送SUBSCRIBE请求，订阅自身的watcherinfo信息。注意其Event头字段的值为presence.winfo。
M1消息如下：
SUBSCRIBE sip:B@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP b.cintel.net.cn;branch=z9hG4bKnashds7
From:
To:
Call-ID: 9987@b.cintel.net.cn
CSeq: 1 SUBSCRIBE
Contact:
Event: presence.winfo
Expires: 3600
Accept: application/watcherinfo+xml
Max-Forwards: 70
Content-Length: 0
2. Presence Server收到请求之后进行鉴权和授权（具体的对watcherinfo的授权由实现自己定义，但是最基本的每个用户应该能够订阅自身的watcherinfo信息）。接受之后返回200响应。（具体对消息的处理流程见参考[23]）
M2消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP b.cintel.net.cn;branch=z9hG4bKnashds7
From:
To:
Call-ID: 9987@b.cintel.net.cn
CSeq: 1 SUBSCRIBE
Contact:
Expires: 3200
Content-Length: 0
3. Presence Server查询出B的watcherinfo信息（A处于“pending”状态，C处于“active”状态），构造成NOTIFY消息通知B。此NOTIFY消息体的格式是“application/watcherinfo+xml”。注意消息体中watcherinfo元素的属性version随着每次发布递增，一般第一次是0。第一次发布的时候应该包含所有记录，因此state属性的值为“full”，后续的发布既可以只包含部分改变的记录也可以包含全部，由实现来决定。
M3消息如下：
NOTIFY sip:B@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKnasaii
From:
To:
Call-ID: 9987@b.cintel.net.cn
CSeq: 1288 NOTIFY
Contact:
Event: presence.winfo
Subscription-State: active;expires=3200
Max-Forwards: 70
Content-Type: application/watcherinfo+xml
Content-Length: 446
version="0" state="full"> status="pending">sip:A@ps.cintel.net.cn status="active">sip:C@ps.cintel.net.cn
4. B收到NOTIFY之后返回200。因为NOTIFY消息体中A的订阅状态为“pending”，因此B终端会弹出提示请求B用户鉴权。这后续的处理和4.2节一样，见上面。
M4消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKnasaii
From:
To:
Call-ID: 9987@b.cintel.net.cn
CSeq: 1288 NOTIFY
Contact:
Content-Length: 0
4.4 发布状态信息 1
2008-02-20 18:36
4.4 发布状态信息
4.4.1 情景说明
假设A有两位好友：B和C，B一直在线，C不在线。A登陆，向Presence Server发布其presence状态，由于C不在线，Presence Server只通知B A的presence状态发生变化。A经一次状态改变和刷新最后发一个取消发布的PUBLISH退出系统。
4.4.2 SIP消息流程图
Figure 5 publication
4.4.3 消息流说明
注：此情景中Presence Server通知B及返回的响应消息与4.1节类似，不再列出这些消息。
SIMPLE规范中把发布（publication）分为四种：Initial、Modify、Refresh和Remove，分别代表初始化、修改、刷新和删除发布（publication）。
发布（publication）机制引入了SIP-ETag和SIP-If-Match头字段。对于每一个成功接受的PUBLISH消息，Presence Server都会分配一个entity-tag并包含在2xx响应的SIP-ETag头字段中。而在下一次的PUBLISH消息中必须带上SIP-If-Match头字段，其值就是上次PUBLISH返回的2xx响应中SIP-ETag的entity-tag。服务器收到这个PUBLISH请求之后会比较SIP-If-Match头字段的值和自己保存的entity-tag。如果匹配，那么接受这个请求，否则拒绝该请求。
上面所提的四种发布（publication）可由是否含有消息体，是否含有SIP-If-Match头字段以及Expires头字段值来确定，如下表：
Operation
Body?
SIP-If-Match?
Expires Value
Initial
yes
no
>0
Refresh
no
yes
>0
Modify
yes
yes
>0
Remove
no
yes
0
Table 1 Publication Operation
以上的具体细节请见参考[8]和[23]。
1. A终端登陆此系统，向Presence Server发送PUBLISH（登陆后首次发送的PUBLISH是Initial类型的），发布自己的新状态。
M1消息如下：
PUBLISH sip:A@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsge
Max-Forwards: 70
To:
From:
Call-ID: 81818181@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3600
Event: presence
Content-Type: application/pidf+xml
Content-Length: 246
entity="sip:A@ps.cintel.net.cn">
4.4 发布状态信息 2
2008-02-20 18:37
2. Presence Server收到PUBLISH请求之后进行鉴权（authentication）和授权（authorization）（具体流程见参考[23]）。接受之后保存A的新状态并为此次发布（publication）分配一个entity-tag，包含在SIP-ETag中返回200。
M2消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsge
To:
From:
Call-ID: 81818181@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3200
SIP-ETag: dx200xyz
Content-Length: 0
3. Presence Server查询A的watcherinfo得知已订阅A的presence状态的有B和C，又查知B当前在线，C不在线。于是Presence Server向B发NOTIFY通知A的新状态，B收到之后返回200。
4. 假设一段时间后A由于工作原因，将状态改为“忙”，于是终端A向Presence Server发送一个Modify类型的PUBLISH，更新其状态。这个PUBLISH中包含一个SIP-If-Match头字段，其值为上一个200响应中SIP-ETag的值。
M5消息如下：
PUBLISH sip:A@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgf
Max-Forwards: 70
To:
From:
Call-ID: 81818182@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3600
Event: presence
SIP-If-Match: dx200xyz
Content-Type: application/pidf+xml
Content-Length: 241
entity="sip:A@ps.cintel.net.cn">
5. Presence Server收到请求之后比较SIP-If-Match与自己保存的entity-tag值，结果一致，于是接受该请求，并调整Expires有效时间长度。保存A的新状态并再次分配一个新的entity-tag包含在SIP-ETag中返回200。
M6消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgf
To:
From:
Call-ID: 81818182@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3200
SIP-ETag: dx300xyz
Content-Length: 0
4.4 发布状态信息 3
2008-02-20 18:37
6. Presence Server发NOTIFY消息给B通知其A的新状态，B收到之后返回200。
7. 在上一次的发布（publication）超时前A重新发了PUBLISH消息，这是个Refresh类型的消息，关键的头字段是Expires，且不含消息体。
M9消息如下：
PUBLISH sip:A@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgg
Max-Forwards: 70
To:
From:
Call-ID: 81818183@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3600
Event: presence
SIP-If-Match: dx300xyz
Content-Length: 0
8. 由于Refresh类型的消息只是刷新发布（publication）的有效时间，并不改变presence状态。因此不需要向订阅A状态的用户发NOTIFY消息。Presence Server选取适当的Expires值并分配新的entity-tag之后返回200。
M10消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgg
To:
From:
Call-ID: 81818183@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3200
SIP-ETag: dx400xyz
Content-Length: 0
9. 最后，A退出系统，向Presence Server发送一个取消发布（publication）的PUBLISH请求。该请求没有消息体，Expires值为0。
M11消息如下：
PUBLISH sip:A@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgh
Max-Forwards: 70
To:
From:
Call-ID: 81818184@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 0
Event: presence
SIP-If-Match: dx400xyz
Content-Length: 0
10. Presence Server收到该请求之后删除A用户对应的一些发布（publication）数据，如expires和entity-tag。返回200完成PUBLISH事务。
M12消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgh
To:
From:
Call-ID: 81818184@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 0
Content-Length: 0
11. 虽然A退出时取消订阅的PUBLISH请求不带消息体，但是A的presence状态发生了变化，变为“Offline”。Presence Server会把新的离线状态保存下来然后发NOTIFY消息通知B，B收到之后返回200。
承接上面的情景，这个NOTIFY的消息体典型如下：
entity="sip:A@ps.cintel.net.cn">
4.4 发布状态信息 3
2008-02-20 18:37
6. Presence Server发NOTIFY消息给B通知其A的新状态，B收到之后返回200。
7. 在上一次的发布（publication）超时前A重新发了PUBLISH消息，这是个Refresh类型的消息，关键的头字段是Expires，且不含消息体。
M9消息如下：
PUBLISH sip:A@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgg
Max-Forwards: 70
To:
From:
Call-ID: 81818183@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3600
Event: presence
SIP-If-Match: dx300xyz
Content-Length: 0
8. 由于Refresh类型的消息只是刷新发布（publication）的有效时间，并不改变presence状态。因此不需要向订阅A状态的用户发NOTIFY消息。Presence Server选取适当的Expires值并分配新的entity-tag之后返回200。
M10消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgg
To:
From:
Call-ID: 81818183@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3200
SIP-ETag: dx400xyz
Content-Length: 0
9. 最后，A退出系统，向Presence Server发送一个取消发布（publication）的PUBLISH请求。该请求没有消息体，Expires值为0。
M11消息如下：
PUBLISH sip:A@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgh
Max-Forwards: 70
To:
From:
Call-ID: 81818184@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 0
Event: presence
SIP-If-Match: dx400xyz
Content-Length: 0
10. Presence Server收到该请求之后删除A用户对应的一些发布（publication）数据，如expires和entity-tag。返回200完成PUBLISH事务。
M12消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgh
To:
From:
Call-ID: 81818184@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 0
Content-Length: 0
11. 虽然A退出时取消订阅的PUBLISH请求不带消息体，但是A的presence状态发生了变化，变为“Offline”。Presence Server会把新的离线状态保存下来然后发NOTIFY消息通知B，B收到之后返回200。
承接上面的情景，这个NOTIFY的消息体典型如下：
entity="sip:A@ps.cintel.net.cn">
4.4 发布状态信息 3
2008-02-20 18:37
6. Presence Server发NOTIFY消息给B通知其A的新状态，B收到之后返回200。
7. 在上一次的发布（publication）超时前A重新发了PUBLISH消息，这是个Refresh类型的消息，关键的头字段是Expires，且不含消息体。
M9消息如下：
PUBLISH sip:A@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgg
Max-Forwards: 70
To:
From:
Call-ID: 81818183@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3600
Event: presence
SIP-If-Match: dx300xyz
Content-Length: 0
8. 由于Refresh类型的消息只是刷新发布（publication）的有效时间，并不改变presence状态。因此不需要向订阅A状态的用户发NOTIFY消息。Presence Server选取适当的Expires值并分配新的entity-tag之后返回200。
M10消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgg
To:
From:
Call-ID: 81818183@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3200
SIP-ETag: dx400xyz
Content-Length: 0
9. 最后，A退出系统，向Presence Server发送一个取消发布（publication）的PUBLISH请求。该请求没有消息体，Expires值为0。
M11消息如下：
PUBLISH sip:A@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgh
Max-Forwards: 70
To:
From:
Call-ID: 81818184@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 0
Event: presence
SIP-If-Match: dx400xyz
Content-Length: 0
10. Presence Server收到该请求之后删除A用户对应的一些发布（publication）数据，如expires和entity-tag。返回200完成PUBLISH事务。
M12消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgh
To:
From:
Call-ID: 81818184@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 0
Content-Length: 0
11. 虽然A退出时取消订阅的PUBLISH请求不带消息体，但是A的presence状态发生了变化，变为“Offline”。Presence Server会把新的离线状态保存下来然后发NOTIFY消息通知B，B收到之后返回200。
承接上面的情景，这个NOTIFY的消息体典型如下：
entity="sip:A@ps.cintel.net.cn">
4.4 发布状态信息 3
2008-02-20 18:37
6. Presence Server发NOTIFY消息给B通知其A的新状态，B收到之后返回200。
7. 在上一次的发布（publication）超时前A重新发了PUBLISH消息，这是个Refresh类型的消息，关键的头字段是Expires，且不含消息体。
M9消息如下：
PUBLISH sip:A@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgg
Max-Forwards: 70
To:
From:
Call-ID: 81818183@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3600
Event: presence
SIP-If-Match: dx300xyz
Content-Length: 0
8. 由于Refresh类型的消息只是刷新发布（publication）的有效时间，并不改变presence状态。因此不需要向订阅A状态的用户发NOTIFY消息。Presence Server选取适当的Expires值并分配新的entity-tag之后返回200。
M10消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgg
To:
From:
Call-ID: 81818183@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3200
SIP-ETag: dx400xyz
Content-Length: 0
9. 最后，A退出系统，向Presence Server发送一个取消发布（publication）的PUBLISH请求。该请求没有消息体，Expires值为0。
M11消息如下：
PUBLISH sip:A@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgh
Max-Forwards: 70
To:
From:
Call-ID: 81818184@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 0
Event: presence
SIP-If-Match: dx400xyz
Content-Length: 0
10. Presence Server收到该请求之后删除A用户对应的一些发布（publication）数据，如expires和entity-tag。返回200完成PUBLISH事务。
M12消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgh
To:
From:
Call-ID: 81818184@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 0
Content-Length: 0
11. 虽然A退出时取消订阅的PUBLISH请求不带消息体，但是A的presence状态发生了变化，变为“Offline”。Presence Server会把新的离线状态保存下来然后发NOTIFY消息通知B，B收到之后返回200。
承接上面的情景，这个NOTIFY的消息体典型如下：
entity="sip:A@ps.cintel.net.cn">
4.4 发布状态信息 3
2008-02-20 18:37
6. Presence Server发NOTIFY消息给B通知其A的新状态，B收到之后返回200。
7. 在上一次的发布（publication）超时前A重新发了PUBLISH消息，这是个Refresh类型的消息，关键的头字段是Expires，且不含消息体。
M9消息如下：
PUBLISH sip:A@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgg
Max-Forwards: 70
To:
From:
Call-ID: 81818183@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3600
Event: presence
SIP-If-Match: dx300xyz
Content-Length: 0
8. 由于Refresh类型的消息只是刷新发布（publication）的有效时间，并不改变presence状态。因此不需要向订阅A状态的用户发NOTIFY消息。Presence Server选取适当的Expires值并分配新的entity-tag之后返回200。
M10消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgg
To:
From:
Call-ID: 81818183@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 3200
SIP-ETag: dx400xyz
Content-Length: 0
9. 最后，A退出系统，向Presence Server发送一个取消发布（publication）的PUBLISH请求。该请求没有消息体，Expires值为0。
M11消息如下：
PUBLISH sip:A@ps.cintel.net.cn SIP/2.0
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgh
Max-Forwards: 70
To:
From:
Call-ID: 81818184@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 0
Event: presence
SIP-If-Match: dx400xyz
Content-Length: 0
10. Presence Server收到该请求之后删除A用户对应的一些发布（publication）数据，如expires和entity-tag。返回200完成PUBLISH事务。
M12消息如下：
SIP/2.0 200 OK
Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgh
To:
From:
Call-ID: 81818184@a.cintel.net.cn
CSeq: 1 PUBLISH
Expires: 0
Content-Length: 0
11. 虽然A退出时取消订阅的PUBLISH请求不带消息体，但是A的presence状态发生了变化，变为“Offline”。Presence Server会把新的离线状态保存下来然后发NOTIFY消息通知B，B收到之后返回200。
承接上面的情景，这个NOTIFY的消息体典型如下：
entity="sip:A@ps.cintel.net.cn">
4.5 删除好友 4.6 添加和删除黑名单
2008-02-20 18:38
4.5 删除好友
4.5.1 情景说明
B是A的好友，A将B删除，B在线。
4.5.2 消息流程图
Figure 6 delete buddy
4.5.3 消息流说明
1. A将B删除。A的终端会将B置上删除标记，并发送XCAP消息DELETE给Presence Server，用以删除服务器端好友列表中的B。
H1消息如下：
DELETE
/services/resource-lists/users/A/buddylist.xml/
~~/resource-lists/list/list/
entry%5b@uri=%22sip:petri@example.com%22%5d HTTP/1.1
Host: ps.cintel.net.cn
2. Presence Server经鉴权后将B从A的好友列表中删除，然后返回一个200响应。
3. 删除B还会影响B的watcherinfo。Presence Server会将B的watcherinfo中A的订阅状态改为“terminated”，对应的事件（event）是“deactivated”。然后发NOTIFY通知B，B返回一个200消息。（当然，如果B当时不在线，那么Presence Server会在B下次登陆的时候通知）。
注：删除好友会不会影响到删除方和被删除方的白名单由具体的实现策略来决定。如果把删除方从被删除方的白名单中去掉，那下次删除方重加好友的时候还需要被删除方的验证；如果把被删除方从删除方的百名单中去掉，那么被删除方虽然还有删除方的好友，但是他不能看见删除方的状态。
4.6 添加和删除黑名单
4.6.1 情景说明
用户可以自己添加或删除黑名单，用以阻止特定人员订阅自己的presence状态。
4.6.2 消息流程图
添加黑名单：
Figure 7 add black list member
删除黑名单：
Figure 8 delete black list member
4.6.3 消息流说明
1. 添加黑名单的方法相当简单，终端只需要向服务器发送一个PUT的XCAP消息，将消息体中的名单添加到URI指定的服务器端黑名单中。服务器端添加成功之后返回200。
2. 删除黑名单与添加黑名单类似，只是方法变为DELETE。这些消息与4.2、4.5节中类似，不再列举。
注：黑白名单是互斥的，一个用户只能存在于一个，不能既是黑名单成员又是白名单成员，实现的时候需要做好这种保障。添加删除黑百名单还有很多由具体实现来决定的策略。比如添加黑名单成员的时候如果该成员原来在好友列表中，那么应该先将其从好友列表中删除，然后再添加到黑名单中。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/xtdxlx126/archive/2009/08/10/4430223.aspx