Browsed by
Author: Gilson

在 Ubuntu 22.04 系统上运行 miniSIPServer

在 Ubuntu 22.04 系统上运行 miniSIPServer

Ubuntu 发布了最新的 LTS (长期支持)版本,即 22.04 (Jammy Jellyfish)。毫无疑问这是个非常重要的商用版本,因此我们有必要详细测试 miniSIPServer 在该系统上的运行状况。

非常幸运,miniSIPServer 可以直接安装、运行,无需任何改动!目前的测试结果表明,运行非常完美! 请参考下图的运行状况。

miniSIPServer 运行在 Ubuntu 22.04 系统
miniSIPServer 运行在 Ubuntu 22.04 系统

如果您打算部署一个新的 VoIP 网络,完全可以选择在 Ubuntu 22.04 版本上运行 miniSIPServer。

call tag 以及 cause

call tag 以及 cause

有时候客户希望知道一些历史呼叫的细节,例如哪一方释放的呼叫、为什么会释放呼叫等。由于这些细节都不是实时呼叫的细节,我们无法用 miniSIPServer 内部的跟踪工具进行跟踪,因此我们更新了 CDR 功能,以便回溯信息、了解呼叫的更深一点的细节。

在 CDR 的 FCI(Furnish Call/Charge Information, “提供呼叫/计费信息”)字段中,我们增加了参数“callTag=”以及”cause=”。请参考下图 CDR 记录的细节:

FCI 字段细节
FCI 字段细节

“callTag=” 参数用于保存当前呼叫的在 miniSIPServer 内部的释放位置,根据这个参数,我们可以知道呼叫在哪里被释放了、以及谁释放了这个呼叫。例如,呼叫有可能是收到了主叫侧的 BYE 消息从而导致释放的,诸如此类。这个参数的具体数值是 miniSIPServer 系统内部值,目前不会向客户们公开具体值的含义。

“cause=” 参数用于保存呼叫释放时的原因值。如果 miniSIPServer 收到了被叫侧的 4xx 或者 5xx 消息、同时该消息中包含 Reason 头域、并且在该域中携带了 cause 参数,则 miniSIPServer 会使用该原因值释放呼叫。其他情况下, miniSIPServer 根据内部的呼叫情况使用自己的 cause 值释放呼叫。当然,无论哪种情况, cause 值都会保存在 CDR 记录的 FCI 字段中。

“回呼”业务更新

“回呼”业务更新

miniSIPServer 默认打开 UDP 端口 5080 接受来自应用服务器的 call-back 请求并发起两路呼叫,如果 miniSIPServer 是部署在公网,有可能收到外部很多不相关的 UDP 数据包。我们可以通过配置“应用服务器地址”进行 IP 地址鉴权,但是不幸的是,这个地址默认是空,miniSIPServer会接受外部数据包并进行后续操作, 这带来隐性危险。

因此我们更新了“回呼”业务,进行适度的保护,同时也稍微修改了业务的处理逻辑。请先参考以下新的配置界面:

回呼业务配置

(1) “应用服务器地址”的默认值修改为本地循环地址“127.0.0.1”,这样外部的数据包将无法通过地址鉴权而被直接抛弃。当然,我们还是可以将它配置为空,允许所有的地址向 miniSIPServer 发送 call-back 请求,但我们强烈建议不要这么配置。

(2) “本地监听端口”可以配置为0,一旦配置为0, miniSIPServer 将关闭“回呼”业务,因此就绝对不会接受外部的任何数据包。如果您的环境没有部署“回呼”业务,我们强烈建议将这一项配置为0。

(3)取消“外线模式”。部分客户经常问道这个配置项是什么意思,也经常被它搞糊涂。其实当初设置这个配置项,主要是让 miniSIPServer 自动在外呼号码前添加“出群呼叫前缀”(默认也就是“9”)。实际上,这个项确实特别不灵活,比如客户可能在“回呼”业务中可能同时呼叫本地分机和外部用户,这个配置就容易导致号码错误。因此我们取消了这一项的配置,如果希望呼叫外部用户,可以在 REQUEST 消息中明确添加出群呼叫前缀。也就是说, 应用服务器自己决定号码格式、自己需要清楚号码分析结果(也就是路由结果)。

请参考“回呼”业务文档了解更多的细节。

Linux 系统启动时自动运行 miniSIPServer

Linux 系统启动时自动运行 miniSIPServer

在以前的 Debian 系统,我们可以更新 rc.local 文件让系统启动时自动运行 miniSIPServer。不过目前的各版本 Debian 已经迁移到 systemd 方式进行管理,因此需要改用其他方式来实现。

首先能采用的方式是保留 rc.local,此时我们需要指示 systemd 激活“rc-local.service”,默认情况下这个 service 是没有激活的,采用以下命令激活即可:

sudo systemctl enable rc-local

这种方式不是一个理想的方式,只能算权宜之计。因为要启动 miniSIPServer, 我们可能不得不更改 rc-local.service,这有可能影响到其他通过同样方式启动的应用程序。

更合理、更好的方式当然是定义独立的 minisipserver.service,由 systemd 单独管理。实际上,这样也是相当简单。我们以树莓派(Raspberry Pi)系统为例,指示 Pi 在系统启动时以 “pi”用户身份启动 miniSIPServer 命令行程序。

我们在目录“/lib/systemd/system”下创建“minisipserver.service”文件,内容如下:

[Unit]
Description=miniSIPServer
After=network.target mariadb.service
Requires=network.target mariadb.service

[Service]
Type=simple
User=pi
KillMode=process
ExecStart=/opt/sipserver/minisipserver-cli

[Install]
WantedBy=multi-user.target

然后使用以下命令激活:

sudo systemctl enable minisipserver

一旦激活了“minisipserver.service”,系统启动或者重启时,将自动运行 miniSIPServer 命令行程序。

上述文件有两个重要的节段:[Unit] 和[Service],我们再进一步解释其中的内容。

Unit

(请点击此处了解 systemd 关于 Unit 节段的详细信息。)

我们关心“After=”和“Requires=”两个参数。

因为 miniSIPServer 是网络应用程序,因此必然要求网络要首先准备好,网络没准备好之前不应该启动 miniSIPServer。

在我们的环境中,miniSIPServer 同时也连接了 mariadb/mysql 数据库,因此也要求在启动之前必须准备好数据库系统。如果您的 miniSIPServer 并没有连接数据库,可以从上述两个参数中删除“mariadb.service”的内容。

Service

(请点击此处了解 systemd 关于 Service 节段的详细信息。)

我们关心“User=”和“ExecStart=”两个参数。

“User=” 指示 systemd 以哪位用户的身份(包括权限)去运行当前业务、启动指定的程序。树莓派系统默认的用户是“pi”,因此我们将其也设置为“pi”即可,在您自己的 Linux 系统,您可以指定为自己实际的相关用户。

miniSIPServer 默认安装在“/opt/sipserver”目录下,命令行程序为“minisipserver-cli”,因此设置“ExecStart=”参数指示 systemd 在启动时找到、并运行该程序。

新的呼叫记录文件格式

新的呼叫记录文件格式

以前的 miniSIPServer 版本将呼叫记录(Call Detail Record,简称CDR)保存为二进制文件,存放在“应用数据/cdr”目录下。如果您希望查询、检查以前的呼叫记录,只能使用自带的 miniCDR 工具打开这些文件。如果希望能做更多的分析和查询,就不得不用 miniCDR 将这些文件转换成 CSV 格式的文件。

现在 miniSIPServer 的新版本(即 V39 或者后续更新的版本)将 CDR 记录直接保存为 CSV 文件。当然,所有的 CSV 文件仍然保存在“应用数据/cdr”目录下。既然 .csv 文件其实都是文本文件,因此您可以使用任何文本工具,例如 Windows 平台下的“记事本”或者 Linux 平台下的 Gedit 等,打开这些 .csv 文件。如果您有微软公司的 Excel 软件,也可以直接打开这些文件并进行分析、查询等。

与此同时,miniCDR 也相应进行了升级。从兼容性考虑, miniCDR 可以同时处理以前的 .cdr 文件和如今的 .csv 文件。

优化:将IVR-XML文件装入内存

优化:将IVR-XML文件装入内存

在多数语音交互的场景中, IVR-XML 文件都比较小,通常是几KB,因此收到呼叫触发 IVR 业务时,服务器都会从硬盘读取 IVR-XML 文件并触发相应的 IVR 流程。但是,如果负荷非常大,例如有大量的并发呼叫同时触发大量的 IVR 流程,miniSIPServer 将频繁读取硬盘上的 XML 文件。显然,这实际会影响服务器的性能。

因此我们做了点优化,将所有的 IVR-XML 文件都装入内存。如果这些文件没有被修改,IVR 业务就直接从内存中读取 XML 文件的内容。如果文件被修改了,miniSIPServer 会自动将修改后的 XML 文件再次装入内存。

这就意味着所有的 IVR 操作都是访问内存,不更改文件的情况下,不会再访问硬盘,miniSIPServer 运行比以前要快一些,在负荷沉重的时候尤其如此。

在 Debian 11 (Bullseye) 系统中运行 miniSIPServer

在 Debian 11 (Bullseye) 系统中运行 miniSIPServer

2021年8月14日,Debian 11(代号 Bullseye)正式发布。这是最新的稳定版本,也是适合商业部署的非常重要的版本,因此我们在该系统中安装、运行 miniSIPServer,并进行了一些测试。结果非常完美!

现有的 miniSIPServer 版本可以毫无障碍地在新系统中运行!您可以参考在线文档了解如何在 Debian 系统中安装、运行 miniSIPServer。

以下是 miniSIPServer 在 Debian 11系统中运行的截图:

在 Debian 11 中运行 miniSIPServer
在 Debian 11 中运行 miniSIPServer
免费版本

免费版本

今天我们增加了一个新的 miniSIPServer 版本(5 客户端版本),这是一个免费版本!您不需要注册码即可长期使用,也不用担心试用期过期的问题。

“5 客户端”版本特别适合微型的 VoIP 网络,例如家庭用户、测试等。您不需要付一分钱就能获得完整的 VoIP 功能特性,当然,SIP/VoIP 客户端数量被限制为不能超过5个。

另外,免费版本不能用于商业目的或者商业场景。

希望您能享受这个新的版本!

转发视频流

转发视频流

如果您使用以前版本的 miniSIPServer,如果想让 miniSIPServer 转发媒体流,miniSIPServer 只会转发语音流而去掉视频流。

这主要是因为视频流会占用太多的带宽,同时也要求服务器有足够的计算能力。很多设备实际上达不到这样的要求。但是越来越多的客户要求我们改进这点,在转发语音流的同时也转发视频流,因为他们的设备目前已经足够强大,而且网络也有足够的带宽。

既然如此,这个要求似乎非常合理,因此我们认为应当升级 miniSIPServer 满足这些客户的需求。

因此最新版本(20210604 构建版本)正式发布,这个版本在转发媒体流的时候,将同时转发语音流和视频流。

升级版本后无需更改配置,您唯一要注意的是硬件的计算能力和网络的带宽是否满足需求。

一个有趣的特性

一个有趣的特性

某些时候我们希望知道系统当前的呼叫状态,例如有那些呼叫、谁正在呼叫等等。miniSIPServer 已有一个“实时话单”窗体,可以显示已经结束的呼叫的话单信息。这个“实时话单“窗体实际上是”半实时“,它无法显示目前还在进行中的呼叫的状态。

显然,我们需要更新这个窗体来显示更多的呼叫细节信息,下面是新版本的”实时话单“窗体:

实时话单窗体
真正的实时话单窗体

这个新窗体将根据呼叫的当前状态,将呼叫标记成不同的颜色。例如,灰色的记录是已经释放的呼叫,黑色记录是刚刚发起的呼叫,蓝色记录是被叫开始振铃的呼叫,而红色记录则是被叫已经应答的呼叫。

根据这些信息,您现在就能非常直观地了解系统当前所有的呼叫细节,相当有趣吧!

当然,您需要指定 miniSIPServer 实时显示话单,并同时指定显示何种话单。请点击菜单“数据 / 系统信息 / 话单”,请参考以下配置:

话单配置项
话单配置项

其中,需要特别注意的是:“产生失败呼叫话单”和“实时显示话单信息”两项必须要勾选中。其他配置项请参考用户手册文档的说明。