对接中国电信IMS网络

对接中国电信IMS网络

最近帮助一位客户部署MSS服务器,对接中国电信IMS网络。在本次对接中,中国电信的软交换是ZTE的设备(至少SIP消息中的User-Agent是这么描述的),存在一些问题,需要特别注意配置方法才能完成对接。

由于中国电信是提供账号、密码信息进行对接,因此在MSS中应配置“外线”,其中需要注意的是以下几个关键点:

鉴权ID

通常外线配置中,不需要设置这项,默认采用“外线/账户”做鉴权ID。而ZTE设备要求采用完整的URI作为鉴权用户名,因此在MSS的外线配置中,必须配置“鉴权ID”项,请参考下图。

外线鉴权ID配置
外线鉴权ID配置

如果不采用完整格式的鉴权用户名,IMS网络会返回“403 Forbidden”拒绝注册和呼叫。我们认为这实际是ZTE软交换的缺陷,因为鉴权信息中本来就携带了域信息,无论鉴权用户名是否携带域信息,应该都不影响鉴权。如果您在与其他IMS设备对接时,也遇到了类似的问题,建议配置完整格式的“鉴权ID”试试。

Proxy设置

在中国电信的IMS网络中,对外的服务器地址作为逻辑域存在,实际上并不可访问。例如,上述例子中的“gd.ctcims.cn”就是域,而不是实际的SIP服务器。SIP消息实际应路由到指定的物理实体(在此我们理解为IMS网络前置的一个SBC或者Proxy),因此在MSS外线配置中,必须指明实际SIP消息需要路由的地址,请参考下图:

IMS网关的物理地址
IMS网关的物理地址
在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试试。希望您能喜欢我们的软件!

SIP中继的并发呼叫数

SIP中继的并发呼叫数

通常我们不限制SIP中继的并发呼叫数,也就是说,默认情况下能呼叫多少就呼叫多少。如果对方资源有限,自然会拒绝多余的呼叫。然而在一些应用场景中,客户们希望MSS能主动对呼叫进行限制。

为此我们拓展了SIP中继中的配置,分别对“呼入呼叫”和“呼出呼叫”的最大并发呼叫数进行限制,超出最大呼叫数的呼叫将被禁止或者抛弃。请参考下图:

SIP中继并发数配置
SIP中继并发数配置

需要注意的是:

(1)这两项配置是独立的,因此可以对呼入和呼出做出不同的限制决定。

(2)如果将其中一项或者两项配置为0,则可以限制为只允许呼入,或者只允许呼出。

一号多机业务的一点修改

一号多机业务的一点修改

在最新发布的V30版本中,对“一号多机”业务做了点改动。原有版本中默认所有分机都具有该业务能力,也就是说,任何一个分机账号都允许多部设备或者话机同时注册和使用。在实际应用过程中,客户们反馈这样做虽然简化了配置,但是其实带来了管理问题,并不想所有分机都允许多机注册,只有部分或者特定的分机才可以这样做。

考虑到这种情况,我们在分机配置中增加了“一号多机”业务权限配置。只有明确配置了该权限位的分机,才允许多机注册和使用。请参考下面的图例。

一号多机权限配置
一号多机权限配置

本次修改同时适用于本地MSS版本以及云MSS版本。

媒体网关与V30版本

媒体网关与V30版本

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

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

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

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

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

话务员业务

话务员业务

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

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

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

在Ubuntu16.10系统上运行miniSIPServer

在Ubuntu16.10系统上运行miniSIPServer

最近释出了最新的Ubuntu版本:16.10,一如既往,我们下载并安装miniSIPServer进行简单的测试。运行很完美,没有任何问题,请参考下图。

Ubuntu 16.10上的miniSIPServer
Ubuntu 16.10上的miniSIPServer

如果您是在商业环境中部署miniSIPServer,我们仍然建议您将Ubuntu保留在以前的LTS版本,即14.04以及16.04等版本。

如果您是在测试环境或者个人环境中部署miniSIPServer,那就请尽情地享受最新的系统带来的快乐吧。

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

阻止匿名呼叫

阻止匿名呼叫

我们可以使用“系统黑白名单”来过滤、阻止匿名呼叫。请点击菜单“业务 – 系统黑名单”,添加以下记录:

caller number prefix = anonymous
called number prefix = *
rate = 100

该记录的作用就是:100%阻断来自“anonymous”的呼叫。

有些匿名呼叫的主叫号码可能会有差别,不过仍然可以在“系统黑名单”配置类似的记录进行过滤。