Browsed by
Category: 版本Release

产品升级、Patch等相关信息发布

在IVR-XML流程中监视各种呼叫事件

在IVR-XML流程中监视各种呼叫事件

在部署 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”的细节。

callto测试脚本下载

上述zip文件是一个简单的IVR-XML脚本示例，用于测试新的“callto”动作。将其解压缩并保存在”xml”子目录下（您可以在miniSIPServer的安装目录下找到这个子目录），并在miniSIPServer中配置新的触发条件进行测试。

配置IVR业务
配置IVR业务
改进”基于 TLS 的 SIP”

改进”基于 TLS 的 SIP”

最近有些客户向我们报告了一个导致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创建自签名的数字证书等文件。

SIP服务器外部地址

SIP服务器外部地址

在最新版本的miniSIPServer中，系统可以同时配置“本地地址”和“外部地址”，如下图所示：

在通常情况下，如果miniSIPServer部署在公网，有公网地址，就无需配置“外部地址”，“本地地址”一般就是公网地址。然而在某些网络环境，例如miniSIPServer部署在私网内，同时又要服务外部用户，此时可以配置“外部地址”，外部的分机采用“外部地址”与miniSIPServer通信。

如果整个网络跨接了多个网段（包括私网-公网，不同的私网等），例如有些分机采用“本地地址”通信，有些分机采用“外部地址”通信，此时建议在分机配置中，设置“转发媒体流”，由miniSIPServer来转发这些分机的语音流。

 

发布长期支持版本V32！

发布长期支持版本V32！

我们终于正式发布V32（长期支持，LTS）版本了！自从发布首个V32测试版本以来，期间经历了数月的时间。在此之间，我们先后更新、优化了各类界面（包括web界面和GUi界面），优化了SIP内核、优化了呼叫基础模块等诸多方面。这是个非常令人兴奋的版本，重要的是，我们将提供长达5年的技术支持！

另一方面，最新的稳定版本V33也同时发布。最重要的一个改变是，从这个版本开始，miniSIPServer 不再支持 X86-32 架构的Debian、Ubuntu系统。新的业务、需求、特性开发将基于V33版本。

希望您能喜欢最新的这些版本！

 

新网站

新网站

我们最近采用 bootstrap 4 重新构建了公司网站，请访问：

https://www.myvoipapp.com/cn/

新界面最重要的特点就是适配了各种访问设备，现在您可以通过PC、手机、平板电脑等访问，各页面会自动调整格式以方便阅读（感谢 bootstrap 4!）。希望您能喜欢我们的新界面！

另一个重要的修改就是“去掉了论坛”。我们对论坛里层出不穷的垃圾广告给搞烦了，大量工作资源耗费在毫无意义的工作上，因此我们决定关闭论坛。如果您有任何问题或者建议，请直接和我们联系即可：

https://www.myvoipapp.com/cn/contact.html

 

V32（稳定版）发布

V32（稳定版）发布

我们已经完成了V32版本绝大部分场景的测试，今天很高兴发布V32稳定版本。

正如您所见，目前V32是处于稳定版本分支。我们完成所有测试用例，并收到足够的客户反馈信息后，V32版本将升级到长期支持版本分支（LTS），预计将在明年年初发布正式版本。

请从我们的网站下载试用。

https://www.myvoipapp.com/cn/download/

希望朋友们能喜欢这个新的版本！

再见，V24！

再见，V24！

V24版本于两年前发布，是MSS第二个长期支持版本。现在，该说再见了！新的长期支持版本将是V32版本，我们将提供5年的支持服务。

V32版本基于目前的稳定版本V31。我们希望在正式发布前做尽可能多的测试，为此我们移除了V24版本的下载链接，仅保留V31版本的下载链接。根据我们的测试进展和客户的使用体验来判断，V31版本已经相当稳定。如果您是初安装MSS或者升级MSS，V31是一个非常好的选择。

V32目前开发、测试顺利，预计在2018年年初的时候发布。

 

V31最终版

V31最终版

我们发布了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自身永远不会发出这类号码格式。

在Debian 9系统上运行miniSIPServer

在Debian 9系统上运行miniSIPServer

很高兴看到最新的Debian 9版本正式发布了，我们在第一时间下载并进行了测试。

Debian 9是个很有趣的版本。考虑到TA是稳定版本，因此未来很多客户可能会选择在这个系统上运行miniSIPServer，确保系统运行正常就显得尤其重要。经过测试，我们吃惊地发现Debian 9相比以前的版本，变更了大量的库文件甚至是系统软件。默认情况下，如果不做任何修改，MSS无法正常运行在这个系统上。

这些天我们花费了大量的时间和资源来解决面临的一些冲突，将MSS的版本升级到最新的V31（build 20170621）。并且我们很高兴地宣布，MSS依然能支持以前的Debian系统，例如Debian 7和Debian 8。目前看一切都很完美！

如果您想尝试Debian 9系统，需要将MSS升级到最新的V31版本。请刷新文档进一步了解依赖库的细节，以便正确运行MSS。

RFC3262与新版本

RFC3262与新版本

RFC3262定义了一种方法，用于SIP对话中传递可靠的临时响应消息。简单地说，就是定义了一个新的SIP消息“PRACK”用于响应“临时响应”消息（是不是很拗口？）。我们一直以来都觉得这不是个好想法，实际上多数传统的SIP设备都没有支持RFC3262定义的能力。

然后最近情况有些变化。在某些需要和传统PSTN网络互通的场景中，各设备必须具备RFC3262能力。尤其是在某些4G-IMS移动网络，例如中国市场的移动网络运营商，如果呼叫中没有指示支持RFC3262能力，网络会直接拒绝呼叫。

所以我们升级MSS到最新的V31版本，主要特性就是支持RFC3262能力。新版本的MSS会在呼出呼叫的消息中明确指示“100rel”，告诉对端设备或者SIP话机可以采用可靠的临时响应消息，这些设备自行决定是否要触发RFC3262的流程。在收到呼叫时，除非对端或者SIP话机明确要求RFC3262流程，否则默认情况下MSS不会主动发起RFC3262流程。这样可以确保同时兼容传统VoIP网络以及IMS网络。

本次升级对用户配置没有任何要求。如果您在部署MSS的过程中，遇到与PSTN网络或者移动IMS网络对接失败的情况时，可以考虑升级到最新的MSS试试。希望您能喜欢我们的软件！