Browsed by
分类:版本Release

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

发布长期支持版本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试试。希望您能喜欢我们的软件!

媒体网关与V30版本

媒体网关与V30版本

昨天我们正式发布了V30版本。正如以前所说,本次版本的主要特性是“媒体网关”。

实际上以前的版本已经有媒体网关功能,只是这些功能与呼叫控制、业务控制融合在同一个核心中,本身并不独立。对于小型或者中型商业部署环境,这样做没有问题(实际上一直运行很好)。但是对大型商业部署而言,比如我们的云通信系统,媒体网关和呼叫控制合并在一起会影响整个系统的性能。

我们决定将“媒体网关”分离出来作为一个独立的应用。在云系统中,“媒体网关”甚至运行在独立的设备上。多台呼叫服务器可以共享、互联同一台媒体网关服务器。

由于本地MSS和云MSS是采用同一个核心模型,因此我们将这个特性也移植回V30版本。不同之处在于:本地MSS将“媒体网关”作为程序内部一个独立的任务(线程)运行。

本次特性修改对配置文件、管理界面没有任何修改。默认情况下,您甚至感觉不到这次的修改。我们相信新的核心更加稳定、更加灵活。希望您能享受、喜欢我们的产品!

话务员业务

话务员业务

在新版MSS中我们增加了两项与话务员相关的业务:话务员强插以及话务员逾越。请参考业务文档了解这两项业务的细节。

本地MSS软件版本以及云MSS服务都为这两个业务进行了升级。目前MSS软件最新版本为V29版本。

下一个版本,即V30版本,将主要集中在“媒体网关”特性的优化上。如果您有任何建议和需求,欢迎您联系我们,我们十分乐意与您进行讨论。

V28与Lua业务

V28与Lua业务

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业务引擎只是后端技术的升级,因此默认情况下您不需要更改任何配置。