一、基于会话启动协议的事件通告机制
1. 事件通告机制的概念
所谓事件通告机制是指网络中的一些实体可以订阅网络中某些资源或呼叫的状态信息， 当那些被订阅的资源的状态发生改变时，负责这一资源的网络实体将向订阅者发送通告，通 报当前资源状态的变化情况。
为了实现这一机制，Internet工程任务组（IETF）的SIP工作组对基本的会话启动协议进 行了扩充，提出了基于会话启动协议的事件通告机制规范：RFC 3265。在规范中定义了两个 扩展方法：订阅（SUBSCRIBE）和通告（NOTIFY）。SUBSCRIBE方法用于发起订阅请求， NOTIFY方法用于通告当前资源状态。
会话启动协议事件通告机制涉及以下几个概念：
♦订阅者
订阅者负责接收NOTIFY消息的会话启动协议用户代理（SIP UA）。这些NOTIFY消息中 包含订阅者订阅的资源信息。订阅者典型的动作是向通告者发送SUBSCRIBE消息以请求创建 一次订阅关系。
♦通告者
通告者负责产生NOTIFY请求的SIPUAo通告者在NOTIFY消息中向订阅者回馈当前资 源的状态。通告者典型的动作是接收SUBSCRIBE消息并创建相应的订阅关系。
♦订阅
所谓订阅就是一组与某个对话相关联的应用状态的集合。订阅关系既存在于订阅者中， 又存在于通告者中。
♦事件包
事件包是通告者向订阅者发送的一组资源的状态信息。RFC 3265中给出了抽象的事件包 模板定义，对应具体业务可定义相应的事件包类型，例如：在席事件包、对话事件包等，这 些事件包可使用不同的语法并具有各自的语义。这种框架赋予会话启动协议事件通告机制极 大的生命力和灵活性，有助于快速提供新的业务。
2. 事件通告机制的流程
典型的会话启动协议事件通告机制流程如图3-2所示。
SUBSCRIBE方法和会话启动协议基本规范中定义的邀请（INVITE）方法都可以创建一 个对话。当订阅者想得到网络中某一资源的状态时，便向负责这一资源的会话启动协议实体 发起SUBSCRIBE请求，如图3-2中的F1所示。SUBSCRIBE消息中的请求统一资源标识符 （Request-URI）就是所要请求的资源的统一资源标识符（URI）,这一 URI同时还为会话启动 协议代理服务器路由请求提供线索。SUBSCRIBE请求中必须包含一个扩展的Event头部，其 中注明要订阅的事件类型，即事件包标记，如，dialog （用于代答业务）、refer （用于呼叫转交） 等。还可包含扩展的Allowed-Event头部，指示本节点能够支持的事件包类型。如果在一个对 话中有多次订阅，则如图3-3所示，在Event头部还要增设标识参数ID予以区分。
对于订阅者来说，它总是在一定的时间段内对它感兴趣的某一资源进行观察。因此， SUBSCRIBE消息中应包含expires头部，这一头部值表明订阅者期望的有效订阅时长。为了 延长某一订阅的时间，订阅者可以在有效期内再次发送SUBSCRIBE消息来刷新这一订阅。具 体某次订阅的有效时长，最终是由对SUBSCRIBE请求的2XX响应中的expires •头部值或 NOTIFY消息中的Subscription-State头部的expires参数决定的。expires头部值等于0的 SUBSCRIBE请求表示撤销订阅。如果订阅关系能够建立，SUBSCRIBE消息将会触发通告资 源状态的NOTIFY消息立即回送。订阅者想要获得的资源状态信息封装在后继通告消息 NOTIFY的消息体中，为了能够正确地解释这部分信息，订阅者应该向通告者指明自己支持的 消息体格式，因此，在SUBSCRIBE消息中应携带Accept头部，例如，Accept: application/dialog-info+xml,这表明订阅者支持用可扩展标识语言（XML）描述的对话事件包， 实际上就是一种通用Internet邮件扩展（MIME）格式消息体。如果SUBSCRIBE消息中没有 携带Accept头部，则通告者根据SUBSCRIBE消息中Event头部指明的事件包标记选择默认 的格式传送资源状态信息。
SUBSCRIBE请求通过2XX响应确认，如图3-2中的F2所示。不同的2XX响应具有不 同的语义：
• 200 OK表示订阅已被接受且用户已被授权订阅请求的资源.
• 202 Accepted （接受）是事件通知机制扩展的响应码，表示订阅请求已被理解，但是 否授权给订阅者未确定。
2XX响应中必须包含expires头部，这个值指明通告者确定的此次订阅的有效时长，且必 须满足：expires 200 OK <= expires SUBSCRIBE,即禁止通告者延长订阅时长。如果返回非2XX 响应，则表示订阅失败，将没有后继的NOTIFY消息。
通告者收到SUBSCRIBE请求时，首先判定是否理解消息中的Event头部，如果不理解， 则通告者返回扩展的“489 Bad Event"（错误事件）响应。通告者还会检查消息中的expires 头部，如果其值满足:（0 < expires SUBSCRIBE < 1 hour） && （ 0 < expires SUBSCRIBE < Min 通 告者-config）,其中，Min通告者-config为通告者最小配置订阅时长，则通告者向订阅者返回 "423 Interval too small"（时间间隔太短）响应，表示提出的订阅时长太短。此外，通告者还 应根据本地策略对提出SUBSCRIBE请求的用户进行鉴权。
与订阅相关的信息由NOTIFY消息传送。通告者在成功创建订阅关系后，必须立即发送 NOTIFY消息，向订阅者通告当前订阅资源的状态，如图3-2中的F3所示。通告者使用 SUBSCRIBE消息中Accept头部明确允许的或者Event头部隐含指明的消息体格式将资源的状 态信息或指向该资源状态的URI封装在消息中。消息也可包含扩展的Allowed-Events头部， 指示本节点能够支持的事件包类型。NOTIFY消息中必须包含扩展的Subscription-State头部， 指示创建的订阅状态。共有3种订阅状态，分别是：
• active:订阅已被接受且授权成功。
• pending: SUBSCRIBE请求已收51）,但还没有足够的信息决定接受或拒绝此次订阅。
• terminated:订阅未激活，或创建的订阅关系终止。
对应active状态或pending状态，该头部还带有expires参数指示此次订阅的有效时长。 对应terminated状态，'该头部应包含reason参数指示订阅被终止的原因，或者包含Retry-After 参数，指示订阅者过一段时间后可重新发起订阅请求。
订阅者收到通告者NOTIFY请求后，将进行匹配检查。
如果找到相应的匹配，且NOTIFY消息中的Subscription-State头部指示的订阅状态是 active或pending,则订阅者创建新的订阅或对话，并对NOTIFY请求回送200 0K响应，如 图3-2中的F4所示。如果匹配失败，则发送"481 Subscription does not exist"（订阅不存在） 响应。
在订阅有效期内，如果资源状态发生变化，则通告者使用NOTIFY请求及时将变化信息 通告订阅者，如图3-2中的F5和F6所示。
扩展的SUBSCRIBE方法和基本的INVITE方法都可以创建对话。在某一对话中， SUBSCRIBE请求将创建和该对话关联的订阅，而该对话有可能是由INVITE建立起来的。因 此，如果订阅终止，且当前无其他应用状态（如由INVITE请求建立起来的应用状态）和该对 话关联，则该对话结束。如果仍有订阅和该对话关联，虽然其他的应用状态已结束，但该对 话并没有结束。换句话说，由INVITE创建的对话并不会因为收到或发送了再见请求而结束， 因为仍有订阅关系和此对话相关联。与此类似，当多个订阅和同一对话关联时，必须当与此 对话相关联的所有订阅都结束时，该对话才结束。这一概念非常类似于程序设计里对文件描 述符的引用，其中文件描述符相当于对话，对文件描述符引用的进程相当于建立的订阅关系。
SUBSCRIBE请求可以触发通告者对其资源状态的立即回送，因此，订阅者可以利用这一 特性实现对资源状态的轮询。当订阅处于激活状态时，订阅者在SUBSCRIBE请求的expires 头部写入当前剩下的订阅有效时长的秒数，这样，能够立即触发通告者产生NOTIFY消息， 将当前资源的状态通告给订阅者。需要指出的是，这种对资源的轮询会导致网络、通告者和 订阅者负荷的增加。在如移动通信这样的特定应用中，订阅者一般是数据处理能力较慢、需 要额外供电的移动终端设备，随着事件通告频度的增加和通告事件包的增大，将消耗很多宝 贵的带宽资源，造成网络拥塞和订阅者的过载。因此，订阅者需要对通告者的状态通告频率 做出限制。另外，订阅者还可以在SUBSCRIBE消息中指定一些事件包的过滤规则，使得通告 者能够根据这一过滤规则产生通告事件，而不是任何状态发生变化时都发起通告。
一般说来，订阅者使用SUBSCRIBE请求建立一次订阅，称为显式订阅创建，与此相对应 的还有一种隐式的订阅创建，即订阅者不是通过SUBSCRIBE请求来创建订阅。而是通过转交 （REFER）方法，一种由RFC 3515定义的用于实现呼叫转交等业务的方法。REFER请求隐 式地在被转交用户处创建订阅，所要观察的资源是转交请求的状态。
3.9.2自动回叫业务示例
如前所述，会话启动协议的事件通告机制非常灵活，针对不同的应用可以定义不同的事 件包，事件包被封装在NOTIFY消息中通告资源状态中，这一机制为实现各种功能强大的业 务提供了坚实的基础。现给出使用这一机制实现的自动回叫业务流程。
♦业务描述
用户A呼叫用户B,而B正在会话，A希望B在通话结束后能够立刻通知他，这样A就 能够及时地和B建立会话了。这里，A使用事件通告机制来获取B的会话状态。
♦业务流程
如图3-4所示，用户A向用户B发起呼叫请求INVITE （Fl）,此时B正在通话，因此返 回“486 Busy Here”（现在正忙）响应（F2）。A希望B能够在通话结束后通知他，于是A向 B发起SUBSCRIBE请求（F4）,其Event头部指明事件类型为dialog,即订阅者B正在进行 中的对话状态；Accept头部指明A支持使用XML语言封装的dialog事件包。
SUBSCRIBE的消息片断如下：
SUBSCRIBE sip: userB@foo.bar SIP/2.0
Event: dialog
Accept: application/d诅log-info+xml
B的通告者根据本地策略对A进行鉴权后授权A订阅这一资源，返回200 OK （F5）,并 立即回送通告当前对话状态的NOTIFY消息。当B结束通话时，A订阅的对话资源状态发生 了变化，从确认状态迁移至了终结状态，B的通告者生成NOTIFY消息，向A通告当前B的
对话状态（F8）. A得到这一信息后，立即向B发起INVITE请求，与B建立新的会话。
三、事件通告机制的安全性考虑
1. 接纳控制
在事件通告机制中，通告者需要将资源的状态信息通告给订阅者。然而，在通告的事件 包中，有些信息对于用户来说是敏感的或者是隐私，因此，通告者应能够根据订阅者的身份, 选择性地拒绝某些用户的订阅请求，并使用标准的会话启动协议鉴权机制对用户进行鉴权。 订阅请求的最终决定权应该由用户（自然人）作岀。
2. 通告者的策略安全
在某些情况下，对SUBSCRIBE请求回应200 OK或4XX、6XX响应可能会导致通告者 某些敏感策略信息的泄露。因此，在这些情况下，通告者应总是对SUBSCRIBE请求回送202 Accepted响应。后继的NOTIFY中可能并不携带真正的资源状态，但从订阅者的角度来看， 这并无任何异常。例如，在“在席”应用中，用户A向用户B发送SUBSCRIBE请求获取用 户B是否在席的信息，B在席，但他拒绝了 A的订阅请求，因为B并不想让A知道他正在网 上。如果B直接使用4XX或6XX响应拒绝，则会泄露B的策略。为此，B可对SUBSCRIBE 回送202 Accepted响应，在随后的NOTIFY消息的Subscription-State头部指明订阅终结，原 因为没有资源，即A想订阅的资源不存在，其Subscription-State头部为：Subscription-State: terminated； reason=noresource,这样既拒绝订阅请求又不会暴露通告者的策略信息。
3. 防止恶意攻击
随着事件通告机制的进一步应用，要逐步考虑应对各种Internet上惯用的恶意攻击。例如， 拒绝服务（DoS）攻击，在当前的基于会话启动协议的事件通告模型中，一个SUBSCRIBE请 求将触发一个或多个通告资源状态的NOTIFY消息，通告者接收到SUBSCRIBE请求，要创 建相应的状态，消耗一定的系统资源。有恶意的订阅者会利用这一点发起过多的订阅请求， 这就有可能使通告者因创建过多的订阅而资源耗尽。为了减少这种攻击的机会，通告者的实 现必须包含鉴权，以过滤恶意的订阅请求。
