Browsed by
Category: 文档和常见问题

技术文档以及常见问题解答

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

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

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

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

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

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

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

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

IP 地址黑白名单配置
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"
检查 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
Request-URI 的附加参数

Request-URI 的附加参数

SIP 网络默认采用 SIP URI 传递信息,例如 From、To等消息头,格式如下:

sip:+8613901088888@ims.bj.chinamobile.com

传统的电信网络一般都是采用 E.164 格式的电话号码,这种格式与 SIP URI 有很大差别,因此 ETSI(3GPP)定义了一种新的 URI,即 TEL URI,格式如下:

tel:+8613901088888

因此在连接电信运营商的 IMS 网络时,通常可能有两种 URI 格式: SIP URI 以及 TEL URI。miniSIPServer 可以支持这两种格式,能够自动处理入呼叫的 TEL URI 格式,但是 miniSIPServer 自己在发出呼叫时,总是采用 SIP URI 格式。

这里有一点问题。幸运的是 IMS 网络考虑非常仔细,例如中国移动可以接受 TEL URI 以及带有特殊参数“user=phone“ 的 SIP URI,格式如下:

sip:+8613901088888@ims.bj.chinamobile.com;user=phone

如果我们配置”外线”连接中国移动的网络,事情就很顺利,因为 miniSIPServer 在外线的呼叫中会自动给 Request-URI 添加“user=phone”。但是在某些市场(区域),中国移动要求采用 SIP 中继的连接方式,这就会导致问题。 miniSIPServer 在中继呼叫中不会对 Request-URI 添加上述参数,因为这种场景我们认为是“服务器 对 服务器”的模式。

为了解决这个问题,我们在 SIP 中继的“出呼叫”配置中增加了“Request-URI 附加参数”项,请参考下图:

Request-URI 附加参数配置
Request-URI 附加参数配置

临时响应的可靠性

临时响应的可靠性

众所周知,RFC3262 协议定义了 SIP 临时响应消息的可靠性。这是个非常古早的特性,miniSIPServer(无论是本地版本,还是云端版本)在很久以前就已经支持这个特性。在与传统电信运营商的 IMS 网络对接时,往往必须要支持可靠的临时响应消息,如果设备不具备此能力,运营商通常会直接拒绝所有的呼叫。

RFC3262 定义了“100rel”参数来指示临时响应消息的可靠性,因此我们在此将其称为“100rel”能力。通常情况下,主叫在发起呼叫时应明确指示出自己是否支持“100rel”能力,被叫也同样需要明确要求采用“100rel”能力,因此呼叫双方才能建立临时响应消息的可靠性。

启动100rel能力的基本呼叫流程

在 RFC3262 标准中,我们可以明确以下细节:

…… the initial request contained a Supported or Require header field listing 100rel, and that there is a provisional response to be sent reliably. ……

UAS core … MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field.

上图描述了可靠临时响应消息的基本流程。UAC 在收到可靠的临时响应 18x 消息时,应当向 UAS 方发送 PRACK 消息,告诉 UAS 自己已经收到了 18x 消息。

这不是一个很复杂的流程,我们一直都认为如此。然而几天前一位云通信用户向我们反映,他无法呼叫外部电话。我们跟踪了他的呼叫,得到以下图描述的呼叫流程:

在 100rel 流程中收到 405 错误消息

难以置信…… 这家 VoIP 运营商升级系统后,在 183 消息中要求采用“100rel”能力确保临时响应的可靠性,然而在 miniSIPServer 发送 PRACK 消息进行确认时,它居然返回“405 method not allowed”。这种情况下当然会导致所有的外呼呼叫都失败了。

这是为什么?!如果不能接受、或者不支持 PRACK 消息,它为什么在临时响应消息(也就是183消息)中明确要求“100rel”呢?

要解决这个问题本来也相当简单。只要在临时响应消息中移除“100rel”、即不要求可靠性保证即可,那样 miniSIPServer 就不会发出 PRACK 消息。但是不幸的是,这家运营商的团队居然不知道该怎么做。

我们的客户就被耽搁在这了,他的业务被迫停滞下来。另一方面,我个人猜测这家(以及某些)运营商采用了开源的服务器,例如 Asterisk、FreeSwitch 等,来构建自己的解决方案,但是他们也许没有足够的专家来理解自己究竟构建了什么。

因此我们更新了 miniSIPServer,在外线的配置中增加一个选项用于关闭“100rel”能力,如下图所示:

关闭临时响应消息的可靠性

一旦勾选了这项, miniSIPServer 向外线发出 INVITE 消息时,将不会再携带“100rel”参数。如果您对接了类似荒谬的运营商,请试试这个选项。

Gnome Calls

Gnome Calls

众所周知,miniSIPServer 可以运行在 Linux 系统,因此常有客户咨询我们是否有 Linux 平台的 SIP 终端软件,大家的初衷是将整个 VoIP 系统构建在 Linux 环境中。实际上 Linux 环境有非常多的选择,例如 linphone、jami 等。

最近发布了一个新的 SIP 软终端,而且非常重要的是,它是 Gnome 项目的核心应用,这就是“Gnome Calls”。在 Debian 的软件库中,这个软件被描述为“Make and receive PSTN phone calls”,而最新版本的 Calls 可以支持 SIP 协议,在 Gnome 项目中的描述已经修改为“Make phone and SIP calls”。

在 Debian 系统中非常容易安装 Calls,请使用以下命令:

sudo apt install gnome-calls

以下截图是 Calls 运行时的主窗体界面:

Gnome Calls 主运行界面
Gnome Calls 主运行界面

点击菜单“VoIP Accounts”即可添加 SIP 账号。大多数项与其他 SIP 终端软件的配置基本一致。例如,在我们的测试环境中, miniSIPServer 的地址是“192.168.3.42”,给终端分配的账号是“100”,请参考以下配置:

SIP 账号配置
SIP 账号配置

请注意:(1)默认的端口是0,建议修改为5060;(2)添加完账号,需要使能后才能向服务器(也就是 miniSIPServer)发起注册、并正常使用。Calls 没有显示账号的运行状态,因此我们需要检查 miniSIPServer 的分机窗体来检视分机的实时状态。

拨打呼叫时,在“Dial Pad”面板直接输入被叫号码(例如101)即可,如下图所示:

拨打呼叫
拨打呼叫

如果有入呼叫,在弹出的窗体中接听、或者拒绝呼叫:

入呼叫处理
入呼叫处理

从各方面使用情况判断,“Gnome Calls”目前还比较简单、粗糙,显然后续还需要加入很多的特性和功能。如果我们希望在 Linux 环境中部署 VoIP 网络、同时希望各网元都是纯粹的 Linux 应用,“Gnome Calls”是个不错的选择。

希望各位也会喜欢这些软件。

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

在IVR-XML流程中监视各种呼叫事件

在IVR-XML流程中监视各种呼叫事件

在部署 miniSIPServer 时,我们可以通过 IVR-XML 来订制自己需要的IVR业务流程,最常见的就是“自动话务员”业务。根据以往的 IVR-XML 功能集,我们可以使用“callto”动作发起新的呼叫,同时结束整个IVR流程。

但是,如果我们想监视呼叫过程中的某些事件,例如“被叫忙”,并根据这些事件改变IVR的流程,触发新的动作(action),我们该怎么做呢?

目前最新的 V37 版本已经发布,在这个版本中,扩展了一个与 IVR-XML 有关的关键特性。我们可以在“callto”动作中,配置“monitor-events”元素,对呼叫事件进行监视,并在事件发生时,将IVR流程转向新的动作。

例如,以下示例中,在“callto”动作中配置需要监视的事件:

<action method="callto" name="mainAction">
    <destination>100<destination>
    <monitor-events>
        <monitor-event detection="busy" nextaction="callto101"/>
    </monitor-events> 
</action> 

在这个示例中,如果“callto”发起的呼叫,遇到被叫忙,则 IVR 流程将执行下一个动作“callto101”, 即对另一个用户发起新的呼叫。

请参考IVR-XML 在线文档,了解更多关于“monitor-events”的细节。

上述zip文件是一个简单的IVR-XML脚本示例,用于测试新的“callto”动作。将其解压缩并保存在”xml”子目录下(您可以在miniSIPServer的安装目录下找到这个子目录),并在miniSIPServer中配置新的触发条件进行测试。

配置IVR业务
配置IVR业务
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。

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