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终端设备。