1、很多用户可能对在线状态功能非常迷惑，简单来说，就是我们中看到的QQ在线不在线状态基本一致。所以，在介绍本章节时，大家可以随时随地结合QQ来对标某些在线状态功能。在线状态中文翻译为在线状态或者呈现状态。比较专业的说法个人认为还是使用在线状态比较合适，当然有其他的的提法完全可能。顾名思义，在线状态就是反映终端用户当前是否在线时的状态情况。在讨论到在线状态时，我们需要首先介绍一个名词Presentity的概念。根据维基百科的定义，Presentity是由两部分名称构成，一个是Entity, 另外一个就是Presence。这里，entity表示是实体，presence表示是一个实体和实体本身所关联的状态信息。这些状态信息用来表示终端当前状态，在线状态可能包括是否空闲，是否有意愿和对端其他人进行即时消息沟通。如果我们和实际工作场景结合起来，读者就会发现，事实上，这个在线状态可能说明这个用户可能正在开会，可能正在忙于其他的事务，也可能是吃饭时间或者其他的茶歇时间，如果对端用户看到这个状态时，可能就不会过多打扰对方。
Presentity必须首先有一个实体，这里，我们叫presentity，还有另外一个对端用户实体，我们称之为watcher。它们之间的关系为订阅者和被订阅者关系。watcher订阅者通过订阅对端的在线状态来实时获得对端的消息，如果被订阅者发生状态改变，订阅者可以获得一个实时的回复消息，订阅者的终端会看到对端状态，这样可以方便进行有效沟通。根据RFC 2778的定义，具体的实现方式如下：
Presentity发布自己本身的状态信息PUBLISH，watcher发布SUBSCRIBE消息来订阅对方的状态。Presence Server工作方式类似于一个代理人身份，转发更新双方的消息。
具体的SIP订阅实现流程图如下图所示：
2、通过SIP实现订阅传输方式很多，但是，大部分的SIP应用程序中使用的是XML的格式来传递订阅和发布的消息内容。这个内容的全称为Presence Information Data Format （PIDF）。发布的数据和订阅数据通过PIDF+XML的格式互相发送。经过多年的发展，PIDF文件格式支持了很多的拓展方式，它们包括：extended PIDF, xpidf+xml, rich PIDF和rpidf+xml，当然还有微软定义的格式。这些格式支持了更多的在线状态的信息，使得在线状态的支持能力得到了进一步的提升，并且更好地支持了多种场景应用。让我们看看以下这个示例所表示的发布消息：
PUBLISH sip:Andrew@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
To: <sip: Andrew@example.com>
From: <sip: Andrew@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com
CSeq: 1 PUBLISH
Max-Forwards: 70
Expires: 3600
Event: presence
Content-Type: application/pidf+xml
Content-Length: 241
<xml version=”1.0″ encoding=”UTF-8″>
<presence xmlns=”urn:ietf:params:xml:ns:pidf”
entity=”pres: Andrew@example.com”>
<tuple id=”efeef223″>
<status>
<basic>open</basic>
</status>
<timestamp>2014-05-01T17:00:19Z</timestamp>
</tuple>
</presence>
当我们讨论SIP订阅时，可能经常会遇到终端聊天的功能或即时消息，语音的支持。IM（即时通讯）目前支持IM的方式包括：XMPP （Extensible Messaging and Presence Protocol）和SIMPLE （Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions）。它们都是负责处理即时消息和在线状态的标准，XMPP在1999年由Jabber 开源社区提出，2004年由IETF修正。SIMPLE也是由IETF在2004年推出。比较有意思的是，这两种方式几乎在同一时间发布，实现的功能和几乎完全相似。网络上有很多类似的技术讨论，我们这里仅简单说明几个比较明显的不同，XMPP更多是一种CS架构方式，希望通过服务器端来控制整个终端双方的状态信息，而SIMPLE这是继承了SIP的基因，更倾向于使用在点对点的双方通信方式。当然，具体的数据结构，信令传输方式和认证方式都有所不同。因为，我们的重点不是讨论IM本身，所以这里不再做过多阐述。
3、现在终端的千变万化给状态管理也带来了很多挑战。上面的介绍中，我们讨论的环境中没有涉及到终端用户的多种状态。事实上，一个SIP账号，用户可能需要以多种方式注册到企业服务器上面，例如，终端可能是SIP物理电话，可能是手机APP，可能是软电话，同时也可能是桌面电脑的SIP软电话等方式。这就要求服务器端支持多种状态的在线方式处理能力。
通过下面的图例我们可以看到，Alex目前可能使用两个终端，两个终端都会向在线服务器发送消息，服务器则需要根据自己的策略来打包发送或者独立发送PIDF数据到订阅端。
当然，也可能通过点对点的方式订阅和发布信息如下图所示，点对点方式则是多方互相发送消息，无服务器转发处理。
4、现在，让我们看看在线服务器的基本工作原理。在线订阅大致通过以下几个步骤来获取在线状态消息。
订阅流程具体经过大概八个步骤，我们上图已标注，这里简述几个重要的步骤：
首先终端需要发送SUBSCRIBE消息，然后查询DNS服务器找到被订阅者服务器地址。
SIP Proxy然后通过地址URL继续发送订阅消息，中间可能经过几个转发服务器。找到最终目的地服务器以后，查询在线状态服务器的数据库，然后返回一个NOTIFY消息。
最后返回NOTIFY消息到本地的SIP Proxy，然后返回到订阅用户。
以上的示例中我们看到的SIP 服务器和在线状态服务器可能是一个服务器，但是很多场景中的在线状态服务器和SIP 服务器是互相独立的，Ramiro Liscano 发表的论文中对SIP 服务器和在线服务器的三层结构做了比较深入的讨论，用户可以参考，这里不再做过多解释。
5、让我们看看具体的数据包。PIDF主要包括几个部分的数据，包括XML 版本，Tuples，status和Medhtods。
以下示例表示了手机端Presnece中的文件格式和Tuples ID。每个Tuple 都有一个唯一的ID，所以终端可获知不同的状态数据。每个Tuple 处于不同的状态，如果Open，则可以进行各种methods支持。另外，还有contact 信息，用户可以对其发送SMS消息。
PUBLISH Method的消息内容：
以下截图是订阅的消息内容，如果用户成功收到订阅消息后，就从subscriber 变成了watcher状态。
Watcher收到的NOTIFY消息：
如果双方需要文本消息沟通，例如发送给对方文本信息时，示例如下：
在文字沟通中，IM比较常见的IM功能 composing 功能。简单来说，就是双方在输入文字时，我们看到终端状态的信息，例如可能形式“正在输入"。这表示对端正在和你进行通讯沟通。如果读者对此功能有兴趣的话，可以查阅RFC3994做进一步了解。
即时通讯中另外一个比较有实用的功能的就是RPID（Rich Presence Extension）定义了更多的客户端状态类型，可以支持各种心情符号图标等等相关状态，这些拓展方式在RFC4480中进行了规定，各种心情状态支持类型如下：
6、我们在前面的讨论中仅单纯讨论了简单的企业内网环境中的在线状态。但是，在实际生产环境中，在线状态服务可能会面对几个方面的挑战：
内网在线状态服务器和外网服务器之间的互联互通。为了安全保证，用户可能需要TLS支持。
在线状态管理的云部署方式可能面对很多问题，以下图例是笔者公司使用的测试在线服务器后台设置，在线服务器可以支持的多种设备类型和终端数量。但是因为国内防火墙的问题，和国外服务器连接时就可能出现问题，实际使用测试中确实也发现一些问题，一些功能可能被阉割。
不同终端同时登录时的状态响应问题也是一个挑战，如果用户使用不同的终端同时在线登录时，watcher 可能会面对状态不一致的问题，这些问题最终取决于不同系统的处理方式。
连接不同在线服务器时的PIDF处理重发机制也是一个挑战，不同用户终端和内网用户进行在线服务连接时，需要一个兼容性非常强大的PIDF网关服务器来进行分发。
是否和目前主流的在线服务器兼容也是一个巨大的挑战，目前，SKYPE是相对比较热门的首先在线服务器解决方案，如果需要大量用户支持时，用户需要考虑这些市场的用户群体，保证在线服务器可以完美兼容这些服务器接入。
压力测试一直是衡量服务器是否稳定的核心指标。大家知道，如果在线服务器或者目前市场上的大部分媒体服务器支持在线功能的订阅的话，事实上，内网的数据交换量是非常惊人的，大部分用户可能也没有注意到这些细节。因为在SIP消息中，不仅仅包含SIP的本身的文本消息，而且还包含PIDF的XML消息，如果所有客户都支持订阅功能的话，服务器平台可能会产生非常庞大的数据交互。所以，一般情况下，如果非用户必须要求开启订阅的话，一般的企业IPPBX最好关闭这些应用功能。在下面的图例中，我们可以看到，如果真正进行在线服务器的处理的话，大概需要经过以下几个步骤，其中一些流程或者参数可能影响在线服务器的性能，它们包括终端请求数量，privacy filter策略，composition policy, watcher filter，partial Notification, UDP/TCP/TLS 影响，DNS查询时间，数据库连接能力，XML解析格式等因素都会影响在线服务器的性能。具体在线服务器压力测试的手段和方法，大家可以根据笔者的参考资料了解，了解更多的细节要素。
7、通过以上所罗列的各种环境的变量，我们可以看到，在线服务器或者企业IPPBX所支持的订阅功能需要大量的带宽来保证数据能够稳定畅通。如果网络带宽不足会导致很多问题，不仅仅是一个订阅功能的问题。但是，网络带宽占用则可能和传输方式，订阅，发布和提示消息的数量，不同的XML文件格式，用户数量之间有着非常直接的关系。这里，SIMPLEstone给出了一个带宽占用的相互关系公式，通过此关系可以计算出大概所需带宽，用户可以参考：
在本章节中，我们主要讨论了关于Presence 在线状态的功能的基本定义，使用场景和PIDF的数据内容，我们还讨论了各种订阅信息的流程和在线服务器的实现流程，同时，我们也讨论了各种消息的具体内容。在部署在线服务器时，客户可能需要面对的一些挑战，例如兼容性问题，网络部署问题，压力测试的影响要素等问题。最后，笔者介绍了如何计算在线服务器的带宽的几个依赖关系，让用户能够充分了解订阅服务具体带宽占用情况。在线状态功能是融合通信中一个必不可少的功能，它可以灵活支持各种终端的状态信息，帮助客户能够非常迅速联系到其他用户。通过我们在本章节的全面介绍，希望给读者一个比较全面的分析帮助读者全面了解这些细节。
参考资料：
https://www.packetizer.com/rfc/rfc3856/
https://msdn.microsoft.com/en-us/library/cc246201.aspx
SIMPLEstone - Benchmarking Presence Server Performance
Ramiro Liscano，Personalization for SIP Multimedia Communications with Presence
关注微信公众号：asterisk-cn，获得有价值的行业分享。访问5060社区-开源IPPBX论坛获得技术帮助：www.ippbx.org.cn
