Browsed by
Tag: voip

在 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 消息中明确添加出群呼叫前缀。也就是说, 应用服务器自己决定号码格式、自己需要清楚号码分析结果(也就是路由结果)。

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

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

话单配置项
话单配置项

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

一个小特性: 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客户及以上版本,您还是必须像以前一样手工配置“端口转发”。

清除“僵尸”虚拟服务器

清除“僵尸”虚拟服务器

在下个月末(2020-01-31),我们将采取行动,清除云通信系统中的“僵尸”虚拟节点。

我们将以下特征的虚拟服务器定义为“僵尸”节点,将在本次行动中被清除。

(1)该虚拟服务器对应的帐号长期没有登录操作。“长期”是指两年以来,即从2017-01-01以来。您可以在最近登陆一次您的帐号,从而避免虚拟服务器被本次行动清除。

(2) 自 2017-01-01 时间点以来,该虚拟服务器没有SIP终端注册,或者没有任何SIP呼叫。

由于“僵尸”虚拟服务器只会无谓占用我们的系统资源,对其他客户也不公平,因此请务必重视本次清理行动,感谢您的理解和支持!

2020-02-13 更新: 本次清理任务已经完成。未来我们将持续清理“僵尸”虚拟服务器,并且不会再进行通知。如果您最近的两年内没有登录过您的服务器节点 ,或者没有任何SIP呼叫,将被视为“僵尸”虚拟服务器被清理掉,请务必重视这点。

在Debian 10系统上运行miniSIPServer

在Debian 10系统上运行miniSIPServer

Debian 10 (Buster) 系统近日已发布。这是最新的稳定版本,也是非常重要的版本。根据Debian的版本发布计划,这个版本是已经可以进行商业部署的版本,因此我们需要对此足够重视。

我们安装了Debian 10版本,并同时安装了miniSIPServer进行了一些测试。我们可以自豪地宣布:目前miniSIPServer的版本无需任何修改,就可以直接在Debian 10系统上运行!请参考以下截图:

miniSIPServer 在 Debian 10 (Buster)系统上运行

祝贺 Debian 社区成功发布最新的版本!