1、很多用戶可能對在線狀態(tài)功能非常迷惑，簡單來說，就是我們中看到的QQ在線不在線狀態(tài)基本一致。所以，在介紹本章節(jié)時，大家可以隨時隨地結合QQ來對標某些在線狀態(tài)功能。在線狀態(tài)中文翻譯為在線狀態(tài)或者呈現(xiàn)狀態(tài)。比較專業(yè)的說法個人認為還是使用在線狀態(tài)比較合適，當然有其他的的提法完全可能。顧名思義，在線狀態(tài)就是反映終端用戶當前是否在線時的狀態(tài)情況。在討論到在線狀態(tài)時，我們需要首先介紹一個名詞Presentity的概念。根據(jù)維基百科的定義，Presentity是由兩部分名稱構成，一個是Entity, 另外一個就是Presence。這里，entity表示是實體，presence表示是一個實體和實體本身所關聯(lián)的狀態(tài)信息。這些狀態(tài)信息用來表示終端當前狀態(tài)，在線狀態(tài)可能包括是否空閑，是否有意愿和對端其他人進行即時消息溝通。如果我們和實際工作場景結合起來，讀者就會發(fā)現(xiàn)，事實上，這個在線狀態(tài)可能說明這個用戶可能正在開會，可能正在忙于其他的事務，也可能是吃飯時間或者其他的茶歇時間，如果對端用戶看到這個狀態(tài)時，可能就不會過多打擾對方。
Presentity必須首先有一個實體，這里，我們叫presentity，還有另外一個對端用戶實體，我們稱之為watcher。它們之間的關系為訂閱者和被訂閱者關系。watcher訂閱者通過訂閱對端的在線狀態(tài)來實時獲得對端的消息，如果被訂閱者發(fā)生狀態(tài)改變，訂閱者可以獲得一個實時的回復消息，訂閱者的終端會看到對端狀態(tài)，這樣可以方便進行有效溝通。根據(jù)RFC 2778的定義，具體的實現(xiàn)方式如下：
Presentity發(fā)布自己本身的狀態(tài)信息PUBLISH，watcher發(fā)布SUBSCRIBE消息來訂閱對方的狀態(tài)。Presence Server工作方式類似于一個代理人身份，轉發(fā)更新雙方的消息。
具體的SIP訂閱實現(xiàn)流程圖如下圖所示：
2、通過SIP實現(xiàn)訂閱傳輸方式很多，但是，大部分的SIP應用程序中使用的是XML的格式來傳遞訂閱和發(fā)布的消息內(nèi)容。這個內(nèi)容的全稱為Presence Information Data Format （PIDF）。發(fā)布的數(shù)據(jù)和訂閱數(shù)據(jù)通過PIDF+XML的格式互相發(fā)送。經(jīng)過多年的發(fā)展，PIDF文件格式支持了很多的拓展方式，它們包括：extended PIDF, xpidf+xml, rich PIDF和rpidf+xml，當然還有微軟定義的格式。這些格式支持了更多的在線狀態(tài)的信息，使得在線狀態(tài)的支持能力得到了進一步的提升，并且更好地支持了多種場景應用。讓我們看看以下這個示例所表示的發(fā)布消息：
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訂閱時，可能經(jīng)常會遇到終端聊天的功能或即時消息，語音的支持。IM（即時通訊）目前支持IM的方式包括：XMPP （Extensible Messaging and Presence Protocol）和SIMPLE （Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions）。它們都是負責處理即時消息和在線狀態(tài)的標準，XMPP在1999年由Jabber 開源社區(qū)提出，2004年由IETF修正。SIMPLE也是由IETF在2004年推出。比較有意思的是，這兩種方式幾乎在同一時間發(fā)布，實現(xiàn)的功能和幾乎完全相似。網(wǎng)絡上有很多類似的技術討論，我們這里僅簡單說明幾個比較明顯的不同，XMPP更多是一種CS架構方式，希望通過服務器端來控制整個終端雙方的狀態(tài)信息，而SIMPLE這是繼承了SIP的基因，更傾向于使用在點對點的雙方通信方式。當然，具體的數(shù)據(jù)結構，信令傳輸方式和認證方式都有所不同。因為，我們的重點不是討論IM本身，所以這里不再做過多闡述。
3、現(xiàn)在終端的千變?nèi)f化給狀態(tài)管理也帶來了很多挑戰(zhàn)。上面的介紹中，我們討論的環(huán)境中沒有涉及到終端用戶的多種狀態(tài)。事實上，一個SIP賬號，用戶可能需要以多種方式注冊到企業(yè)服務器上面，例如，終端可能是SIP物理電話，可能是手機APP，可能是軟電話，同時也可能是桌面電腦的SIP軟電話等方式。這就要求服務器端支持多種狀態(tài)的在線方式處理能力。
通過下面的圖例我們可以看到，Alex目前可能使用兩個終端，兩個終端都會向在線服務器發(fā)送消息，服務器則需要根據(jù)自己的策略來打包發(fā)送或者獨立發(fā)送PIDF數(shù)據(jù)到訂閱端。
當然，也可能通過點對點的方式訂閱和發(fā)布信息如下圖所示，點對點方式則是多方互相發(fā)送消息，無服務器轉發(fā)處理。
4、現(xiàn)在，讓我們看看在線服務器的基本工作原理。在線訂閱大致通過以下幾個步驟來獲取在線狀態(tài)消息。
訂閱流程具體經(jīng)過大概八個步驟，我們上圖已標注，這里簡述幾個重要的步驟：
首先終端需要發(fā)送SUBSCRIBE消息，然后查詢DNS服務器找到被訂閱者服務器地址。
SIP Proxy然后通過地址URL繼續(xù)發(fā)送訂閱消息，中間可能經(jīng)過幾個轉發(fā)服務器。找到最終目的地服務器以后，查詢在線狀態(tài)服務器的數(shù)據(jù)庫，然后返回一個NOTIFY消息。
最后返回NOTIFY消息到本地的SIP Proxy，然后返回到訂閱用戶。
以上的示例中我們看到的SIP 服務器和在線狀態(tài)服務器可能是一個服務器，但是很多場景中的在線狀態(tài)服務器和SIP 服務器是互相獨立的，Ramiro Liscano 發(fā)表的論文中對SIP 服務器和在線服務器的三層結構做了比較深入的討論，用戶可以參考，這里不再做過多解釋。
5、讓我們看看具體的數(shù)據(jù)包。PIDF主要包括幾個部分的數(shù)據(jù)，包括XML 版本，Tuples，status和Medhtods。
以下示例表示了手機端Presnece中的文件格式和Tuples ID。每個Tuple 都有一個唯一的ID，所以終端可獲知不同的狀態(tài)數(shù)據(jù)。每個Tuple 處于不同的狀態(tài)，如果Open，則可以進行各種methods支持。另外，還有contact 信息，用戶可以對其發(fā)送SMS消息。
PUBLISH Method的消息內(nèi)容：
以下截圖是訂閱的消息內(nèi)容，如果用戶成功收到訂閱消息后，就從subscriber 變成了watcher狀態(tài)。
Watcher收到的NOTIFY消息：
如果雙方需要文本消息溝通，例如發(fā)送給對方文本信息時，示例如下：
在文字溝通中，IM比較常見的IM功能 composing 功能。簡單來說，就是雙方在輸入文字時，我們看到終端狀態(tài)的信息，例如可能形式“正在輸入"。這表示對端正在和你進行通訊溝通。如果讀者對此功能有興趣的話，可以查閱RFC3994做進一步了解。
即時通訊中另外一個比較有實用的功能的就是RPID（Rich Presence Extension）定義了更多的客戶端狀態(tài)類型，可以支持各種心情符號圖標等等相關狀態(tài)，這些拓展方式在RFC4480中進行了規(guī)定，各種心情狀態(tài)支持類型如下：
6、我們在前面的討論中僅單純討論了簡單的企業(yè)內(nèi)網(wǎng)環(huán)境中的在線狀態(tài)。但是，在實際生產(chǎn)環(huán)境中，在線狀態(tài)服務可能會面對幾個方面的挑戰(zhàn)：
內(nèi)網(wǎng)在線狀態(tài)服務器和外網(wǎng)服務器之間的互聯(lián)互通。為了安全保證，用戶可能需要TLS支持。
在線狀態(tài)管理的云部署方式可能面對很多問題，以下圖例是筆者公司使用的測試在線服務器后臺設置，在線服務器可以支持的多種設備類型和終端數(shù)量。但是因為國內(nèi)防火墻的問題，和國外服務器連接時就可能出現(xiàn)問題，實際使用測試中確實也發(fā)現(xiàn)一些問題，一些功能可能被閹割。
不同終端同時登錄時的狀態(tài)響應問題也是一個挑戰(zhàn)，如果用戶使用不同的終端同時在線登錄時，watcher 可能會面對狀態(tài)不一致的問題，這些問題最終取決于不同系統(tǒng)的處理方式。
連接不同在線服務器時的PIDF處理重發(fā)機制也是一個挑戰(zhàn)，不同用戶終端和內(nèi)網(wǎng)用戶進行在線服務連接時，需要一個兼容性非常強大的PIDF網(wǎng)關服務器來進行分發(fā)。
是否和目前主流的在線服務器兼容也是一個巨大的挑戰(zhàn)，目前，SKYPE是相對比較熱門的首先在線服務器解決方案，如果需要大量用戶支持時，用戶需要考慮這些市場的用戶群體，保證在線服務器可以完美兼容這些服務器接入。
壓力測試一直是衡量服務器是否穩(wěn)定的核心指標。大家知道，如果在線服務器或者目前市場上的大部分媒體服務器支持在線功能的訂閱的話，事實上，內(nèi)網(wǎng)的數(shù)據(jù)交換量是非常驚人的，大部分用戶可能也沒有注意到這些細節(jié)。因為在SIP消息中，不僅僅包含SIP的本身的文本消息，而且還包含PIDF的XML消息，如果所有客戶都支持訂閱功能的話，服務器平臺可能會產(chǎn)生非常龐大的數(shù)據(jù)交互。所以，一般情況下，如果非用戶必須要求開啟訂閱的話，一般的企業(yè)IPPBX最好關閉這些應用功能。在下面的圖例中，我們可以看到，如果真正進行在線服務器的處理的話，大概需要經(jīng)過以下幾個步驟，其中一些流程或者參數(shù)可能影響在線服務器的性能，它們包括終端請求數(shù)量，privacy filter策略，composition policy, watcher filter，partial Notification, UDP/TCP/TLS 影響，DNS查詢時間，數(shù)據(jù)庫連接能力，XML解析格式等因素都會影響在線服務器的性能。具體在線服務器壓力測試的手段和方法，大家可以根據(jù)筆者的參考資料了解，了解更多的細節(jié)要素。
7、通過以上所羅列的各種環(huán)境的變量，我們可以看到，在線服務器或者企業(yè)IPPBX所支持的訂閱功能需要大量的帶寬來保證數(shù)據(jù)能夠穩(wěn)定暢通。如果網(wǎng)絡帶寬不足會導致很多問題，不僅僅是一個訂閱功能的問題。但是，網(wǎng)絡帶寬占用則可能和傳輸方式，訂閱，發(fā)布和提示消息的數(shù)量，不同的XML文件格式，用戶數(shù)量之間有著非常直接的關系。這里，SIMPLEstone給出了一個帶寬占用的相互關系公式，通過此關系可以計算出大概所需帶寬，用戶可以參考：
在本章節(jié)中，我們主要討論了關于Presence 在線狀態(tài)的功能的基本定義，使用場景和PIDF的數(shù)據(jù)內(nèi)容，我們還討論了各種訂閱信息的流程和在線服務器的實現(xiàn)流程，同時，我們也討論了各種消息的具體內(nèi)容。在部署在線服務器時，客戶可能需要面對的一些挑戰(zhàn)，例如兼容性問題，網(wǎng)絡部署問題，壓力測試的影響要素等問題。最后，筆者介紹了如何計算在線服務器的帶寬的幾個依賴關系，讓用戶能夠充分了解訂閱服務具體帶寬占用情況。在線狀態(tài)功能是融合通信中一個必不可少的功能，它可以靈活支持各種終端的狀態(tài)信息，幫助客戶能夠非常迅速聯(lián)系到其他用戶。通過我們在本章節(jié)的全面介紹，希望給讀者一個比較全面的分析幫助讀者全面了解這些細節(jié)。
參考資料：
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，獲得有價值的行業(yè)分享。訪問5060社區(qū)-開源IPPBX論壇獲得技術幫助：www.ippbx.org.cn
