我们发布了V31最终版本，也就是说我们未来的工作将集中于V32版本，这将是我们下一个LTS版本，取代发布已久的V24版本。

实际上，V31版本包含了很多重要特性。由于V31版本是V32版本的基线版本，因此我们仍然会在这个版本上持续更新和维护数月时间。请参考下面的章节了解几个关键更新的细节。

工具链更新

主要指Windows平台的工具链更新。

V31版本升级了几个重要工具。首先是VC++升级到VC2010，因此MSS将采用VC2010的运行库。VC2010比之前的VC2008要强大一些，另外在处理manifest问题时要好得多。

基础的SSL库从OpenSSL迁移到LibreSSL库。当然，在Linux平台，MSS目前仍然使用OpenSSL库，未来可能会统一到LibreSSL库。LibreSSL提供了官方的windows库，我们认为LibreSSL优化得比OpenSSL要好很多。如果部署了“SIP over TLS”，这次库替换会比以前版本更稳定、更安全。

SIP协议栈更新

最近我们和几位客户配合处理一些与IMS网络互联互通的问题。我们遇到了几个奇怪、老旧的SIP呼叫流程，并通过优化V31来适配这些需求。

首先是支持“18x 带/不带 SDP”流程。“18X”可以是180，也可以是183，因此您可以看到流程存在多种可能性，例如“180带SDP”、“180不带SDP”、“183带SDP”以及“183不带SDP”等。同时这些消息的顺序也是有差异的， 有些场景中我们先收到180，另一些场景中又先收到183消息。在多数场景中，这些消息实际用于播放不同的回铃音，因此对这些流程的支持，不仅仅涉及修改SIP模块，MSS内部的媒体连接处理实际上也相应作出了优化。

另一个关键点是对SIP-UPDATE消息的支持。某些IMS网络不通过18x消息来携带回铃音信息，它们转而使用SIP-UPDATE消息。我们也发现某些设备采用“SIP-UPDATE不带SDP信息”来保持对话的激活状态。这些处理非常有趣，我们希望在另一篇blog中比较深入仔细地讨论与此有关的流程。不管怎样，V31版本专门为此进行更新，支持了部分SIP-UPDATE功能流程。我们并没有完整支持这个消息的所有功能，同时MSS本身也不会主动发起SIP-UPDATE流程。如果MSS希望更改媒体，目前仍然是采用reINVITE消息及其处理过程。

在V31版本中，MSS也支持“tel”号码格式。在传统的软交换网络，软交换设备和PSTN网络互通时，有可能将这样的号码格式传递给MSS，我们不是很理解为什么这些软交换设备不将其转换成VoIP域的SIP-URL格式。现在V31支持对方发送这类号码格式，同样，MSS自身永远不会发出这类号码格式。