Browsed by
Author: Gilson

Debian 以及 Ubuntu 版本支持问题

Debian 以及 Ubuntu 版本支持问题

最新的 miniSIPServer V60版本发布后,对 Debian 以及 Ubuntu 的版本支持做出了修改。Debian 最低版本要求是 oldoldstable 版本,即目前的 V10 版本,也就是说 miniSIPServer 后续将不再支持 Debian V8、V9等版本。

考虑到 Ubuntu 实际是基于 Debian 的系统,因此相应的最低版本要求变更为 Ubuntu V18.04。

请参考在线文档了解 miniSIPServer 对 Linux 系统的最低要求及相关细节。

会议室以及其他

会议室以及其他

近日 miniSIPServer 升级到V60版本,这是最新的、可用于商业部署的稳定版本。第一个重大特性就是“会议室”业务,该业务支持不超过 5 个本地分机用户的会议呼叫。请参考业务文档了解细节。miniSIPServer 云也同步升级支持该业务。

另外,正如我们在前一篇博客中提到,V60 业务最终移除了部分老旧的业务,例如呼叫卡、话吧。这些业务曾经对我们某些特定的客户非常重要,但就目前而言该对这些业务说再见了。

优化 miniSIPServer

优化 miniSIPServer

大约 20 年前我们开发并发布了 miniSIPServer,期间我们为越来越多的客户加入了非常多的特性和业务。

最近我们重新审视了 miniSIPServer 的所有业务。其中有些业务的历史非常悠久,我们判定这些业务可能已经无法适应目前的环境(或者说在当前环境下已经没有实用意义),例如“话吧”、“呼叫卡”等各类业务。

下一个版本将优化(或者清除)这类老旧的业务,miniSIPServer 将步入新的阶段,会变得更快、更稳定、更适合新的 VoIP 网络需求。

如果您需要部署 FXS 网关,……

如果您需要部署 FXS 网关,……

FXS(Foreign Exchange State,外部交换站)网关用于将传统电话设备连入 VoIP 域,一般网络拓扑如下所示:

VoIP 域 <--> miniSIPServer <--> FXS 网关 <--> 传统电话

一般一台 FXS 网关连接一台传统电话,但有些 FXS 网关也能同时接入多台传统电话,此时需要特别注意。

FXS 网关连接多台传统电话时,需要多个 SIP 分机账号对应接入 miniSIPServer。另外,网关有可能采用一个地址(IP 地址+端口)与 miniSIPServer 建立连接、注册分机账号。这也就是说,多个分机账号会采用同一个地址。

如果网关内某个账号配置错误,网关会不停用错误信息向 miniSIPServer 注册,此时会触发“失败则阻止”,miniSIPServer 会屏蔽掉该网关的地址。如前所述,网关内的 SIP 账号都采用了同一个地址,因此这实际上会导致其他账号同时注册失败。

在这种情况下,我们需要为该网关关闭“失败则阻止”,即将网关的地址加入白名单。请点击菜单“业务 – IP地址黑白名单”,增加记录接受网关的IP地址。如下图所示:

IP 地址黑白名单配置
在 Ubuntu 24.04 (Noble Numbat)系统中运行 miniSIPServer

在 Ubuntu 24.04 (Noble Numbat)系统中运行 miniSIPServer

Ubuntu 24.04 是最新的 LTS(长期支持)版本,很显然在商业环境中将会有很广泛的部署。我们安装了这个重要的版本,并运行 miniSIPServer 进行了一些测试。测试结果非常不错,运行界面如下图所示:

在 Ubuntu 24.04 系统上运行 miniSIPServer

如果您希望在 Linux 环境中部署一个新的 VoIP 系统,那 Ubuntu 24.04 是个不错的选择。

请参考在线文档了解如何在 Linux 系统部署 miniSIPServer 的更多细节。

支持 TLSv1.3

支持 TLSv1.3

我们最近更新了 miniSIPServer 以支持 TLSv1.3。本次修改不影响配置,如果您升级 miniSIPServer 到最新版本,无需修改任何配置。

miniSIPServer 有两个模块有可能用到 TLSv1.3:(1)SIP 服务器模块;以及(2)嵌入式 HTTP 服务器模块。如果您的 SIP 话机(或者软电话)支持 TLSv1.3,那采用这个协议将能更好地保护您的通信。请参考《基于 TLS 的 SIP》了解更多细节。目前本地 miniSIPServer 和云端 miniSIPServer 都可以支持基于 TLSv1.3的 SIP 通信。

本地 miniSIPServer 采用内嵌式 HTTP 服务器提供 web 管理,默认没有加密。如果您需要或者希望通过公共网络管理、配置 miniSIPServer,那么建议启用加密传输的 HTTP 服务。目前主流的浏览器,例如Chrome、Edge、Firefox 等,都支持 TLSv1.3,请参考《Web 管理》配置和启用加密的HTTP。

ARM64 以及一些修改

ARM64 以及一些修改

正如大家所知,miniSIPServer有一些专门为树莓派(Raspberry Pi)定制的版本,这些版本都是基于 armhf 架构。最近越来越多的客户向我们咨询在 arm 系统上运行的 miniSIPServer,经调查,大部分都是 arm64 架构的服务器或者板载系统。

据此我们将为特定的树莓派系统定制的 miniSIPServer 修改为普适性的、基于 ARM64 架构的 miniSIPServer。当然,树莓派也支持 arm64 架构,因此这次的修改基本能覆盖大部分的 arm 架构应用场景。

另一方面,这些应用场景的大部分客户都只需要命令行方式的 miniSIPServer,他们并不需要图形界面的 miniSIPServer,也就是说他们只需要运行 minisipserver-cli 就可以了。默认情况下, miniSIPServer 安装包会要求安装 qtbase5-dev 库以支持图形界面,而此类场景中实际已经不需要这个库了,因此我们修改了 miniSIPServer 安装包的 deb-control 控制参数,将 qtbase5-dev 包从‘Depends’段改到‘Suggests’段。

如果您希望运行图形界面的 miniSIPServer,则需要用以下命令安装依赖库:

sudo apt install gcc g++ qtbase5-dev

如果您只是希望运行命令行方式的 miniSIPServer, 则需要以下命令安装依赖库:

sudo apt install gcc g++
181 Call Is Being Forwarded

181 Call Is Being Forwarded

“呼叫前转”是 VoIP 以及通信领域非常传统的业务。默认一般是由 SIP 终端(话机)发送 3xx 消息给 miniSIPServer 进行呼叫前转,当然 miniSIPServer 自身也可以直接发起呼叫前转。

大多数情况下,主叫侧并不知道被叫侧发生了呼叫前转,主叫侧也并不关心被叫侧的呼叫是否被前转了。然而,有些时候主叫侧确实需要知道被叫侧的呼叫前转。

miniSIPServer 目前会向主叫侧发送 181 Call Is Being Forwarded 消息,明确告知主叫:被叫侧正发生呼叫前转。在 181 消息中,miniSIPServer 增加了一个 Call-Info 头域携带前转的必要信息。请参考下图:

呼叫前转流程中的 181 消息及 Call-Info 信息

上图的流程发生了两次前转:(1)被叫 B 被前转到被叫 C;以及(2)被叫 C 被前转到被叫 D。

181 消息的 Call-Info 头域将携带以下信息:(1)呼叫正在被前转;(2)谁发生了呼叫前转;以及(3)前转呼叫的目标用户。请参考上图第一个 181 消息(即被叫 B 前转到被叫 C)中的 Call-Info 头域细节:

Call-Info: purpose=forwarding, username="userb", contact="userc"
外线的 RequestURI 参数

外线的 RequestURI 参数

miniSIPServer 与 VoIP 服务器(网关)通过外线连接,发送消息(例如 REGISTER 或者 INVITE等消息)时会在 Request-URI 中自动附加参数“user=phone”。这是来自中国移动的要求。多数情况下这种做法都没有问题,在 RFC3261 规范中也明确定义了 RequestURI 的附加参数。

然而事情总有意外。最近有些客户向我们反映,miniSIPServer 与他们的 VoIP 服务商网络对接失败,对方服务器无法识别 RequestURI 的参数。当然,简单的方法自然是这些服务商升级自己的服务器,遵循 RFC3261 标准规范的定义,这样大家都会很舒适。

其中个别运营商坚持目前的状态,不愿意做出任何改变。那怎么办呢?我们不得不在外线的配置做出一点修改,请参考下图:

外线的 RequestUR 附加参数配置

我们在外线的“出呼叫”配置中,增加了一项“Request-URI 附加参数”。客户们可以根据自己的网络状况来设置该项的值。

需要说明的是,如果是中文界面,我们默认客户是在中国的网络环境下配置外线,因此该项的默认值是“user=phone“,而其他语种的界面中,该项默认为空。我们认为这样的处理可以满足全球各种网络环境的要求。

该修改已经应用于本地版本的 miniSIPServer 以及云端版本的 miniSIPServer,欢迎大家试用。

检查 DNS 结果

检查 DNS 结果

最近一位 miniSIPServer 云通信系统客户报告了一个问题,他的 SIP 电话全部都离线了,无法注册到虚拟服务器。我们检查了网络和对应的虚拟节点,结果一无所获。

我们试图跟踪来自该用户分机的 SIP 消息,但同样跟踪不到任何消息。这说明来自客户侧的 SIP 消息都丢失了,但是测试表明他的本地网络很正常,其他网络应用都没有问题,唯独 SIP 网络宕机了。

这确实非常奇怪。最终客户发现他本地的 DNS 记录由于不可知的原因被修改了,本地 ISP 对虚拟服务器的 DNS 查询记录返回了错误的地址。将 DNS 服务器配置为腾讯的 DNS 服务器地址后,问题解决,他的 VoIP 网络回归正常。

如果您的所有 SIP 电话都离线了,同时又发现网络是正常工作状态,您可以试试检查 DNS 记录。我们建议以下小技巧对比检查本地 ISP 的 DNS 记录与腾讯 DNS 记录。

如果您的工作系统是 Windows 系统,可以使用 nslookup 命令检查 DNS 结果。例如,我们指定通过腾讯的 DNS 服务器(即‘119.29.29.29’)查询虚拟服务器‘1425.s1.minisipserver.com’的 DNS 记录,命令如下所示:

nslookup 1425.s1.minisipserver.com 119.29.29.29

如果您的工作系统是 Linux 系统,可以使用 dig 命令查询 DNS 结果,如下所示:

dig @119.29.29.29 1425.s1.minisipserver.com 

您可以按照上述方法再检查本地 ISP 的 DNS 结果。如果结果与腾讯的 DNS 结果不一致,那说明(1)您本地的 ISP 屏蔽了我们的云通信系统,或者(2)本地 ISP 的 DNS 记录由于不可知的原因被污染了。

我们推荐在 VoIP 网络环境中采用腾讯DNS 服务器(地址是 119.29.29.29),或者阿里DNS 服务器(地址是 223.5.5.5)。

另外,Debian 系统默认没有 dig 命令,您需要安装 dnsutils 包获得该工具:

sudo apt install dnsutils