产品升级、Patch等相关信息发布
在部署 VoIP 网络时， 有些场景会要求使用定制化的资源文件，例如 自己的语音文件、特殊的 IVR 流程、自己的鉴权文件等。 以前的 miniSIPServer 版本将这些文件保存在安装运行目录（或者子目录）下。
这有可能导致管理方面的问题。卸载、升级 miniSIPServer 时，我们不得不非常小心地备份这些定制的资源文件。
V38 (build 20210108) 版本试图解决这个困扰。 所有的定制化资源文件和默认的资源文件分离出来，单独保存在应用数据目录（AppData 目录）及其子目录下。
例如，定制的语音文件将保存在 custAnn 子目录中。一旦 miniSIPServer 被卸载或者升级，这些语音文件不会受任何影响。
请参考在线文档了解更多细节。
在部署 miniSIPServer 时，我们可以通过 IVR-XML 来订制自己需要的IVR业务流程，最常见的就是“自动话务员”业务。根据以往的 IVR-XML 功能集，我们可以使用“callto”动作发起新的呼叫，同时结束整个IVR流程。
但是，如果我们想监视呼叫过程中的某些事件，例如“被叫忙”，并根据这些事件改变IVR的流程，触发新的动作（action），我们该怎么做呢？
目前最新的 V37 版本已经发布，在这个版本中，扩展了一个与 IVR-XML 有关的关键特性。我们可以在“callto”动作中，配置“monitor-events”元素，对呼叫事件进行监视，并在事件发生时，将IVR流程转向新的动作。
例如，以下示例中，在“callto”动作中配置需要监视的事件：
<action method="callto" name="mainAction"> <destination>100<destination> <monitor-events> <monitor-event detection="busy" nextaction="callto101"/> </monitor-events> </action>
在这个示例中，如果“callto”发起的呼叫，遇到被叫忙，则 IVR 流程将执行下一个动作“callto101”， 即对另一个用户发起新的呼叫。
请参考IVR-XML 在线文档，了解更多关于“monitor-events”的细节。
上述zip文件是一个简单的IVR-XML脚本示例，用于测试新的“callto”动作。将其解压缩并保存在”xml”子目录下（您可以在miniSIPServer的安装目录下找到这个子目录），并在miniSIPServer中配置新的触发条件进行测试。
最近有些客户向我们报告了一个导致miniSIPServer崩溃的问题，所有这些客户都部署了“基于TLS的SIP”，所有的崩溃报告都显示是SSL/TLS加密库内部崩溃。基于这些信息，我们更新了miniSIPServer，在新版本中做了以下一些关键修改：
（1）SSL库升级到最新的版本；
（2）默认将只保留TLSv1.2加密方式，SSLv2、SSLv3、TLSv1以及TLSv1.1都被禁止。在我们调查问题的过程中，我们发现有些黑客企图利用SSLv3的缺陷骇入miniSIPServer，出于安全防护的考虑，我们全部移除这些有隐患的加密方式。未来我们会考虑加入更多更安全的加密方式，比如TLSv1.3。目前如果要部署“基于TLS的SIP”，必须确保SIP终端或者电话也支持TLSv1.2加密方式。
另一方面，我们也更新了“基于TLS的SIP”文档。在文档中新增了一些简单的示例，演示使用openSSL创建自签名的数字证书等文件。
在最新版本的miniSIPServer中，系统可以同时配置“本地地址”和“外部地址”，如下图所示：
在通常情况下，如果miniSIPServer部署在公网，有公网地址，就无需配置“外部地址”，“本地地址”一般就是公网地址。然而在某些网络环境，例如miniSIPServer部署在私网内，同时又要服务外部用户，此时可以配置“外部地址”，外部的分机采用“外部地址”与miniSIPServer通信。
如果整个网络跨接了多个网段（包括私网-公网，不同的私网等），例如有些分机采用“本地地址”通信，有些分机采用“外部地址”通信，此时建议在分机配置中，设置“转发媒体流”，由miniSIPServer来转发这些分机的语音流。
我们终于正式发布V32（长期支持，LTS）版本了！自从发布首个V32测试版本以来，期间经历了数月的时间。在此之间，我们先后更新、优化了各类界面（包括web界面和GUi界面），优化了SIP内核、优化了呼叫基础模块等诸多方面。这是个非常令人兴奋的版本，重要的是，我们将提供长达5年的技术支持！
另一方面，最新的稳定版本V33也同时发布。最重要的一个改变是，从这个版本开始，miniSIPServer 不再支持 X86-32 架构的Debian、Ubuntu系统。新的业务、需求、特性开发将基于V33版本。
希望您能喜欢最新的这些版本！
我们最近采用 bootstrap 4 重新构建了公司网站，请访问：
新界面最重要的特点就是适配了各种访问设备，现在您可以通过PC、手机、平板电脑等访问，各页面会自动调整格式以方便阅读（感谢 bootstrap 4!）。希望您能喜欢我们的新界面！
另一个重要的修改就是“去掉了论坛”。我们对论坛里层出不穷的垃圾广告给搞烦了，大量工作资源耗费在毫无意义的工作上，因此我们决定关闭论坛。如果您有任何问题或者建议，请直接和我们联系即可：
https://www.myvoipapp.com/cn/contact.html
我们已经完成了V32版本绝大部分场景的测试，今天很高兴发布V32稳定版本。
正如您所见，目前V32是处于稳定版本分支。我们完成所有测试用例，并收到足够的客户反馈信息后，V32版本将升级到长期支持版本分支（LTS），预计将在明年年初发布正式版本。
请从我们的网站下载试用。
https://www.myvoipapp.com/cn/download/
希望朋友们能喜欢这个新的版本！
V24版本于两年前发布，是MSS第二个长期支持版本。现在，该说再见了！新的长期支持版本将是V32版本，我们将提供5年的支持服务。
V32版本基于目前的稳定版本V31。我们希望在正式发布前做尽可能多的测试，为此我们移除了V24版本的下载链接，仅保留V31版本的下载链接。根据我们的测试进展和客户的使用体验来判断，V31版本已经相当稳定。如果您是初安装MSS或者升级MSS，V31是一个非常好的选择。
V32目前开发、测试顺利，预计在2018年年初的时候发布。
我们发布了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”，这次库替换会比以前版本更稳定、更安全。
最近我们和几位客户配合处理一些与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自身永远不会发出这类号码格式。
很高兴看到最新的Debian 9版本正式发布了，我们在第一时间下载并进行了测试。
Debian 9是个很有趣的版本。考虑到TA是稳定版本，因此未来很多客户可能会选择在这个系统上运行miniSIPServer，确保系统运行正常就显得尤其重要。经过测试，我们吃惊地发现Debian 9相比以前的版本，变更了大量的库文件甚至是系统软件。默认情况下，如果不做任何修改，MSS无法正常运行在这个系统上。
这些天我们花费了大量的时间和资源来解决面临的一些冲突，将MSS的版本升级到最新的V31（build 20170621）。并且我们很高兴地宣布，MSS依然能支持以前的Debian系统，例如Debian 7和Debian 8。目前看一切都很完美！
如果您想尝试Debian 9系统，需要将MSS升级到最新的V31版本。请刷新文档进一步了解依赖库的细节，以便正确运行MSS。