SIP keep-alive方法

在SIP族協議中，只有RFC4028明確討論了對話keep-alive問題。實際上這在工程應用、生產環境部署中，是個很是重 要的話題，尤 其是SIP基於UDP協議時，網絡緣由丟包是很常見的，另外還有軟終端任意退出對話等狀況。缺少keep-alive保護的SIP服務器毫無疑問將會嚴重 消耗資源，最終致使整個server被迫退出服務。

RFC4028協議考慮到有狀態Proxy、無狀態Proxy等狀況，提出擴展 Session-Expires以及Min-SE兩個新的 Header，而且經過reINVITE消息來keep-alive dialog。基本上，這個協議自己沒有太多問題，按照它的思路，的確是能夠解決keep-alive的問題，可是在實際部署中，該協議未必可取，有很大 的缺陷：

（1）SIP運營商可能會拒絕reINVITE消息。實際上不少SIP運營商會拒絕reINVITE消息，這是出於SIP運營 商媒體處理方面的考 慮。最初應用reINVITE就是爲了修改媒體流，而這毫無疑問會致使SIP運營商媒體服務器從新分配資源等狀況出現。RFC4028中只是定義了新增 Header和callFlow，不幸的是，卻沒有區分出這個reINVITE與更改媒體流的reINVITE，所以實際部署時是否有效，咱們須要打一個 很大的問號。

（2）採用reINVITE流程太太重型了。正如前面所說，keep-alive的reINVITE消息是沒有與更改媒體 流的reINVITE進行 區分，所以能夠確定絕大部分SIP服務器或者終端，在收到這個reINVITE消息時，會啓動媒體更改流程。對話內重改媒體毫無疑問是個很重型的流程，一 旦對話內自己就可能有媒體類業務，例如Music On Hold等，就頗有可能致使衝突。

若是不採用reINVITE消息，在4028協議中也同時建議能夠採用UPDATE消息。在UPDATE消息中能夠不攜帶SDP更改媒體。這種方式多是比較可行，可是未必全部的SIP設備會支持UPDATE消息並用於keep-alive過程。

方案之二應該採用SIP最基礎協議RFC3261中定義的OPTIONS消息。理由以下：

（1）該消息定義在RFC3261協議中，這個協議是整個SIP協議族的基礎。基本上不可能有SIP設備（包括服務器、Proxy、終端等）會不支持這個消息。

（2）咱們注意到，這個消息能夠在對話內，也能夠在對話外使用。在RFC3261中很明確地定義了：

An OPTIONS request received within a dialog generates a 200 (OK) response that is identical to one constructed outside a dialog and does not have any impact on the dialog.

（3）對話內使用OPTIONS，最顯著的優勢就是「does not have any impact on the dialog」，對現有對話沒有任何影響，更不可能去更改媒體。

（4）對端設備若是因爲某種緣由已經退出，固然就不能產生200OK響應消息，此時能夠理所固然地拆除當前對話，從而保護服務器自身資源，達到keep-alive的目的。

對 於設備層級的keep-alive，採用OPTIONS沒有任何問題。可是對於dialog層級的keep-alive，則會有問題。緣由在 於：dialog內的OPTIONS消息有可能被對端做爲對話外的OPTIONS來處理。也就是說，若是設備是alive的，可是dialog的BYE消 息丟失了，不管dialog內仍是dialog外，設備對OPTIONS均可能會返回200OK。

Requests that do not change in any way the state of a dialog may be received within a dialog (for example, an OPTIONS request).  They are  processed as if they had been received outside the dialog.

方案三是採用RFC5626協議，對於UDP-SIP的狀況，該協議建議採用STUN keep-alive方式。缺陷在於：定義有些複雜，並且不少SIP設備未必會支持。

呼叫服務器和媒體服務器合一的狀況下，固然也能夠由媒體服務器檢測RTP/RTCP來keep-alive，不過這是另一個topic了，這種方式可能更合適於SIP終端設備。