产品升级、Patch等相关信息发布
昨天我们正式发布了V30版本。正如以前所说，本次版本的主要特性是“媒体网关”。
实际上以前的版本已经有媒体网关功能，只是这些功能与呼叫控制、业务控制融合在同一个核心中，本身并不独立。对于小型或者中型商业部署环境，这样做没有问题（实际上一直运行很好）。但是对大型商业部署而言，比如我们的云通信系统，媒体网关和呼叫控制合并在一起会影响整个系统的性能。
我们决定将“媒体网关”分离出来作为一个独立的应用。在云系统中，“媒体网关”甚至运行在独立的设备上。多台呼叫服务器可以共享、互联同一台媒体网关服务器。
由于本地MSS和云MSS是采用同一个核心模型，因此我们将这个特性也移植回V30版本。不同之处在于：本地MSS将“媒体网关”作为程序内部一个独立的任务（线程）运行。
本次特性修改对配置文件、管理界面没有任何修改。默认情况下，您甚至感觉不到这次的修改。我们相信新的核心更加稳定、更加灵活。希望您能享受、喜欢我们的产品！
在新版MSS中我们增加了两项与话务员相关的业务：话务员强插以及话务员逾越。请参考业务文档了解这两项业务的细节。
本地MSS软件版本以及云MSS服务都为这两个业务进行了升级。目前MSS软件最新版本为V29版本。
下一个版本，即V30版本，将主要集中在“媒体网关”特性的优化上。如果您有任何建议和需求，欢迎您联系我们，我们十分乐意与您进行讨论。
V28版本正式发布！我们在这个版本花费了数月的时间。 本版本的关键特性是新的业务引擎，即“Lua业务引擎”。
如您所知，以前的MSS版本的业务引擎采用Python语言编写，工作得非常好，但是仍然有一些限制。现在新版本中业务引擎采用Lua语言重新编写，我们简单介绍作出这一决定的几个关键因素。
（1）Lua语言更简单。Python是全栈、通用型语言，而Lua是嵌入式语言。Lua比Python少很多特性，但是胜在更简单。我们尽管非常喜欢Python，但是分析后仍然发现Lua更适合用于MSS来实现业务引擎。我们不需要全功能，只需要能封装、提供MSS核心功能和能力即可。
（2）最重要的稳定性。Python业务引擎采用一个Python虚拟机支持所有的业务实例，一旦其中一个业务发生未知异常导致虚拟机崩溃，所有的业务都会收到影响。而在新的业务引擎中，每个业务都会采用一个单独的Lua虚拟机，如果一个业务发生未知异常，其他业务不会受到任何影响。这实在是太棒了！整个MSS系统的稳定性达到了更高水平！
（3）更快！更快！更快！仅仅是语言层面，Lua就比Python更快。由于GIL的存在，Python无法满足高性能的要求，因此只能被局限在业务引擎层面。而Lua没有这个限制，每个Lua虚拟机都很微小而且独立，我们现在只是用Lua替换了业务引擎，后续我们甚至可以考虑实现基本呼叫引擎，未来已来！
在V28版本中，所有的Python业务已经被替换为Lua业务。您可以在“lua/services”子目录中找到这些Lua业务文件。如果您曾经自行修改过Python文件，升级到新版本后您需要自行修改对应的Lua文件。
由于Lua业务引擎只是后端技术的升级，因此默认情况下您不需要更改任何配置。
昨天发布了最新的Ubuntu16.04版本，这同时也是最新的LTS（长期支持）版本，因此我们尽快地下载了该版本并作了相当程度的测试。
有很多库升级或者改变了，我们需要更新miniSIPServer来适应这些变化。如果您希望在16.04系统上运行miniSIPServer，或者您希望将已有的Ubuntu系统升级到16.04版本，您需要更新到新的miniSIPServer版本（build 20160422）。
其他没有什么区别。请参考下图中我们运行miniSIPServer的情况：
一位客户向我们报告：他的MSS服务器可能被黑客攻击。我们一起检查了MSS产生的呼叫详细话单，数据显示某人用另外一部SIP电话注册了同样一个分机号，并产生了大量的呼叫。
很显然，这是个非常严重的问题。我们推测这位“黑客”可能采用了发送大量SIP消息的方式来尝试上述分机的密码，并最终破解了密码。MSS以前的版本没有考虑这种异常情况，总是会允许SIP话机不停使用密码进行鉴权，直到最终通过鉴权为止，这就导致某些人刻意不停地扫描和尝试分机和密码。
为阻止这种情况，我们升级了MSS的版本，提供“失败则阻止（fail to ban， F2B）”特性。一旦SIP话机在一分钟内鉴权失败了若干次，则MSS会视之为“恶意扫描”并屏蔽其IP地址若干小时，期间MSS将拒绝所有来自该IP地址的SIP消息。这样迫使某些人几乎不可能破解SIP分机的密码。
F2B特性默认就开启，并且用户无需做任何配置。
最近我们更新了V25版本，修正了一些bug、做了一些优化，系统更加稳定。最重要的是：从这个版本开始，我们删除了webRTC特性。
在以前的blog或者文档中，我们说明了MSS webRTC特性适用于Google Chrome浏览器。Chrome升级到V48版本后，对webRTC特性做了一些改动。一如以往，这些改动没有考虑到和以前版本的兼容，这迫使我们再次不得不向客户道歉并跟进修改。综合考虑后我们认为，可能webRTC特性更适合公众网络业务，例如Google自身的hangouts业务。缺乏灵活性、兼容性考虑，webRTC可能不适合中小型企业通信网络市场。
因此我们从V25版本开始砍掉了这个特性，不过仍然保留在V24（LTS版本）中。如果您仍然在使用webRTC特性，请注意保持Chrome浏览器的版本不要超过V47版本。
本特性已经合入最新的V25版本（build 20160126）。
某些特殊的SIP设备，例如自动控制系统中的嵌入式SIP设备，往往不具备全SIP能力集，只能发起或者接受简单的SIP呼叫，不能进行账号和密码鉴权。部分设备甚至不支持发送“注册”消息到MSS更新自己的状态。
嗯，我们在MSS中可以将这些设备配置为“SIP中继”，但是这样也会丢掉一些关键特性，例如“振铃组”。在某些场景中，客户们希望能让所有设备同时振铃，这样我们就只能将设备配置为“分机”用户。
为满足这些需求，我们在“分机”中增加了“IP地址鉴权”的特性。也就是说，MSS可以不要求SIP终端首先进行注册，呼叫过程中也可以不再对账号和密码进行鉴权，只要SIP消息来自特定的或者预先配置的IP地址即可。请参考下图了解更多的细节：
另外，在新版本中我们同样也更新了openAPI文档，如果您有兴趣的话，可以参考最新的文档。
2016年就要来临了，祝大家新年快乐！万事如意！
在这喜庆的时节，我们将miniSIPServer长期版本升级到V24，稳定版本升级到V25版本，这是今年最后一次升级，也是一次非常重要的升级。
祝各位朋友假期愉快！
同时也希望您重返工作时能喜欢我们的新版本！:-)
在“语音邮箱”业务中，MSS需要采用SMTP库发送语音邮件。考虑到MSS本身支持嵌入Python脚本，因此很容易就直接调用python-smtplib库发送邮件。这正是我们在以前的版本中的实现方式，一直工作得很好，我们也很满意。
然而smtplib库（python2.7携带）有点过时了，无法满足一些现代SMTP服务器的要求。另外，该库也有一个明显的缺陷：它是同步方式。这意味着发送邮件的过程中，会阻塞业务线程，导致性能低下。这在普通PBX应用场景中不是问题，但是在我们的云端通信系统中就显得不太合适了。
事情已经发生改变，我们也希望MSS能更加完美，因此决定开发一个新的SMTP库来发送邮件。新的SMTP库采用异步方式，有更高的性能，符合现代SMTP的各项要求。并且，采用C/C++语言实现。
我们已经更新了V23版本和云通信系统，都采用了最新的SMTP库。希望您能喜欢最新的版本。
另外，自从V23版本发布数月以来，我们得到的反馈非常之好，因此我们想是时候发布新的长期支持版本（即V24版本）以及新的稳定版本（即V25版本）了。按照版本计划，如果没有意外的话，我们将在今年年底或者明年年初完成上述版本的升级，敬请期待！
昨天发布了MSS最新的V23版本。本次版本发布主要支持的特性是：shared-appearance（SA，共享呈现）。在“一号多机”业务中，同一个号码下的分机可以订阅其他分机的状态，MSS会实时将其他分机的状态通知到订阅分机，例如：振铃、应答、终结，诸如此类的状态。
需要强调的是，这个特性对SIP电话的能力也有相应的要求。SIP电话应支持SUBSCRIBE/NOTIFY等操作。如果您的电话不具备这些能力，这个特性将自动取消。
SA特性不要求任何配置。是不是很简单？希望您能享受这个特性带来的便利！