Browsed by
Tag: SIP

一个小特性: UPnP

一个小特性: UPnP

在部署 VoIP 网络时,经常会遇到“语音不通”或者“语音单通”等问题。这通常都是由于私有网络导致的,例如,部分 SIP 电话和 miniSIPServer 部署在路由器后面,而部分 SIP 设备(包括 SIP 电话)部署在另一个不同的网(可以是私网、也可以是公网)。

为解决这类语音问题,通常我们都建议在路由器中手工配置“端口转发”,将必要的一些端口转发到 miniSIPServer,由 miniSIPServer 来负责转发不同网之间的语音流。 如果您对路由器比较熟悉,配置“端口转发”相对就比较容易。

然而部分客户不熟悉路由器配置,或者在配置时可能会出些错误,因此我们在 miniSIPServer 中增加了个小特性来帮助完成“端口转发”的配置。

这就是UPnP(Universal Plug and Play, 通用即插即用)。 UPnP 能帮助 miniSIPServer 自动进行端口映射。

首先,您需要确认路由器支持UPnP,并且已经打开了这项功能。

接着,在 miniSIPServer 的主窗体,请点击菜单“数据 – 系统配置”,并选择配置项“采用 UPnP 请求路由器映射端口”即可,如下图所示:

miniSIPServer 中的 UPnP 配置
miniSIPServer 中的 UPnP 配置

默认情况下,miniSIPServer 会请求映射以下端口: SIP (基于UDP)端口、转发媒体流的端口。

另一方面,多数路由器(尤其是家用级别的路由器)会限制 UPnP 请求的端口数量,比如通常会少于30个,因此如果您的 miniSIPServer 是100客户及以上版本,您还是必须像以前一样手工配置“端口转发”。

使用“SIP over TLS”接入云通信系统

使用“SIP over TLS”接入云通信系统

我们最近升级了云端miniSIPServer系统,加入了一些重要的特性。其中,最重要的特性就是支持“SIP over TLS”。

默认情况下,云系统打开 TCP 6060端口接受基于 TLS 加密的 SIP 消息(即 SIP over TLS)。该特性对所有虚拟节点都有效,无需额外付费,也无需额外进行配置。

现在 SIP 电话可以采用加密的 SIP 消息连接到云端 miniSIPServer,但是对于“外线”或者“SIP中继”,仍然只能用传统的、基于 UDP 的普通 SIP 消息与 VoIP 运营商对接。

“SIP over TLS”仅用于加密SIP消息。如果您希望同时加密媒体流,例如加密语音流和视频流,您应当在话机或者终端中配置 SRTP。默认情况下,媒体流不经过 miniSIPServer,只是终端之间自行处理。

请参考在线文档“基于TLS的SIP”了解更多的细节。

T-MSS 和 L-MSS

T-MSS 和 L-MSS

部分客户在全球有多个分支机构(或者分支办公室),部署多个miniSIPServer服务器,建立企业内部统一的VoIP通信网络,如下图所示:

多分支机构VoIP网络拓扑
多分支机构VoIP网络拓扑

我们提供了一个简单的文档描述这种网络部署情况,其中引入了两个重要的逻辑实体概念: T-MSS 和 L-MSS。

L-MSS 即“本地miniSIPServer,Local miniSIPServer”,部署在各分支机构或者分支办公室,连接当地的网络,服务于本地分机用户和网关设备等。

T-MSS 即“中继miniSIPServer, Trunk miniSIPServer”,用于桥接所有分支机构的L-MSS。

点击此处了解更多的细节信息。

改进”基于 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创建自签名的数字证书等文件。

规整的openAPI开放接口文档

规整的openAPI开放接口文档

miniSIPServer 提供开放的openAPI接口,客户可以在自己的系统中,通过这些接口操作、管理miniSIPServer。

以前的openAPI文档托管在GitBook网站上,目前我们已经重新移植回我们的官方网站,请访问以下链接获得最新的接口文档。

https://www.myvoipapp.com/cn/docs/mss_services/openapi/index.html

在新的文档中,我们开放了更多的接口,几乎覆盖了基本呼叫所需要的所有配置项,例如SIP中继、外线、路由等。

希望接口文档对您的解决方案有帮助。如果您希望我们开放更多的接口,请联系我们。我们欢迎任何建议!谢谢!

转接到下一个中继

转接到下一个中继

在使用SIP中继外呼时,有可能遇到对方无法呼出的情况,例如对方资源全忙等,此时如果用户配置有多条SIP中继、同时又是对接多个不同的服务商,MSS可以继续尝试另一个SIP中继进行外呼。

在MSS的SIP中继中配置“呼叫失败时尝试另一中继”,并指定后续处理的中继即可。如下图所示:

配置SIP中继的后续转接中继
SIP中继呼出失败时,转而尝试另一中继。
外线配置

外线配置

部署VoIP网络时,我们常常会在miniSIPServer中配置外线连接VoIP运营商的服务器。考虑到市场中有大量的VoIP运营服务商,因此经常有客户咨询我们如果配置miniSIPServer来连接这些运营商的网络。

实际上在“小型企业建立IP-PBX系统指南”这篇指导文档中,我们已经提供了一个简单的外线配置,连接VoIP运营商“call centric”。您可以参考这篇文章了解VoIP网络和外线的相关细节。另一方面,我们在“常见问题”文档的“外线”章节,也给出了一些其他运营商的配置参考。如果您有兴趣或者需求的话,也可以参考这些文档,希望这些文档帮助您部署VoIP网络。

https://www.myvoipapp.com/cn/docs/faq/index.html

在Ubuntu 18.04上运行miniSIPServer

在Ubuntu 18.04上运行miniSIPServer

安装完Ubuntu后,从我们网站上下载miniSIPServer V32版本,直接点击安装,非常简单!稍微测试了一下,完美!

由于18.04版本是最新的长期支持版本,因此我们也强烈推荐客户使用这个版本来部署miniSIPServer。

miniSIPServer运行在 Ubuntu 18.04
miniSIPServer运行在 Ubuntu 18.04

再见,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自身永远不会发出这类号码格式。