Browsed by
Category: 产品

MyVoIPApp出品的各种产品

“回呼”业务更新

“回呼”业务更新

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 实时显示话单,并同时指定显示何种话单。请点击菜单“数据 / 系统信息 / 话单”,请参考以下配置:

话单配置项
话单配置项

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

优化的振铃组业务

优化的振铃组业务

一般情况下,我们在用户的配置文件中设置振铃组业务。一个用户只能设置一个振铃组,在多数情况下,这个设定都能工作得很好。

众所周知,现在是艰难时刻。部分公司不得不裁剪人力资源以减少运营费用,因此剩余的人员就可能需要承担更多的工作。比如同一个员工有可能同时分配到多个工作组(振铃组)。实际上已经有一些客户要求我们适配这个需求。

我们非常理解这个请求,因此升级了 miniSIPServer, 采用一个新的方式来支持振铃组业务。

简而言之就是新增了两张表。一张表用于定义振铃组及其分机用户,请参考下图:

振铃组用户

另一张表配置了振铃组检测方式,miniSIPServer 根据呼叫中的被叫号码,判定是否需要触发振铃组。请参考下图:

振铃组检测

业务文档已经更新,请点击此处了解更多细节。

定制的资源文件

定制的资源文件

在部署 VoIP 网络时, 有些场景会要求使用定制化的资源文件,例如 自己的语音文件、特殊的 IVR 流程、自己的鉴权文件等。 以前的 miniSIPServer 版本将这些文件保存在安装运行目录(或者子目录)下。

这有可能导致管理方面的问题。卸载、升级 miniSIPServer 时,我们不得不非常小心地备份这些定制的资源文件。

V38 (build 20210108) 版本试图解决这个困扰。 所有的定制化资源文件和默认的资源文件分离出来,单独保存在应用数据目录(AppData 目录)及其子目录下。

例如,定制的语音文件将保存在 custAnn 子目录中。一旦 miniSIPServer 被卸载或者升级,这些语音文件不会受任何影响。

请参考在线文档了解更多细节。