Browsed by
Category: 技术文档

归纳整理后的技术文档

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
临时响应的可靠性

临时响应的可靠性

众所周知,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”参数。如果您对接了类似荒谬的运营商,请试试这个选项。

在 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
在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。

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

SIP中继的并发呼叫数

SIP中继的并发呼叫数

通常我们不限制SIP中继的并发呼叫数,也就是说,默认情况下能呼叫多少就呼叫多少。如果对方资源有限,自然会拒绝多余的呼叫。然而在一些应用场景中,客户们希望MSS能主动对呼叫进行限制。

为此我们拓展了SIP中继中的配置,分别对“呼入呼叫”和“呼出呼叫”的最大并发呼叫数进行限制,超出最大呼叫数的呼叫将被禁止或者抛弃。请参考下图:

SIP中继并发数配置
SIP中继并发数配置

需要注意的是:

(1)这两项配置是独立的,因此可以对呼入和呼出做出不同的限制决定。

(2)如果将其中一项或者两项配置为0,则可以限制为只允许呼入,或者只允许呼出。

一号多机业务的一点修改

一号多机业务的一点修改

在最新发布的V30版本中,对“一号多机”业务做了点改动。原有版本中默认所有分机都具有该业务能力,也就是说,任何一个分机账号都允许多部设备或者话机同时注册和使用。在实际应用过程中,客户们反馈这样做虽然简化了配置,但是其实带来了管理问题,并不想所有分机都允许多机注册,只有部分或者特定的分机才可以这样做。

考虑到这种情况,我们在分机配置中增加了“一号多机”业务权限配置。只有明确配置了该权限位的分机,才允许多机注册和使用。请参考下面的图例。

一号多机权限配置
一号多机权限配置

本次修改同时适用于本地MSS版本以及云MSS版本。

Invalid CSeq number

Invalid CSeq number

最近一位客户报告了一个问题:他的外线始终无法注册到VoIP运营商的网络。这让人倍感奇怪,毕竟“外线”是MSS非常基础的功能,已经和众多VoIP运营商对接过,我们从没想到过“外线注册”居然会有问题。

抓取了相应的log,发现该运营商返回了“400 Bad Request”消息,其中携带了以下原因信息:

P-Registrar-Error: Invalid CSeq number

我们检查了REGISTER消息,MSS在处理CSeq时并没有任何问题。以下是MSS消息的摘要:

==>
REGISTER sip:sip.xxx.com SIP/2.0
...
Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001.
CSeq: 13 REGISTER
...

<==
SIP/2.0 401 Unauthorized
...
Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001.
CSeq: 13 REGISTER
...

==>
REGISTER sip:sip.xxx.com SIP/2.0
...
Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001.
CSeq: 14 REGISTER
...

<==
SIP/2.0 400 Bad Request
...
Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001.
CSeq: 14 REGISTER
P-Registrar-Error: Invalid CSeq number
...

我们再次检查了RFC3261规范中的定义:

A UA MUST increment the CSeq value by one for each REGISTER request with the same Call-ID.

显然我们是完全正确的,但是为什么对端会拒绝了注册呢?

最终我们尝试修改了Call-ID参数后注册成功。这让我们更感困惑!RFC3261规范很清楚地说明了注册流程中Call-ID参数的注意事项:

All registrations from a UAC SHOULD use the same Call-ID header field value for registrations sent to a particular registrar.

我们认为这个VoIP运营商的系统是不专业的。不幸的是,该运营商很难去升级他们的系统,因此我们在MSS中增加了一个开关变量来控制这种情况:

[sip]
gVarSipRegSameDialog=0

如果您在与某些VoIP运营商系统对接时遇到类似的问题,请在“mss_var_param.ini” 文件中增加上述参数并重启MSS。

对抗SIP扫描

对抗SIP扫描

一位客户向我们报告:他的MSS服务器可能被黑客攻击。我们一起检查了MSS产生的呼叫详细话单,数据显示某人用另外一部SIP电话注册了同样一个分机号,并产生了大量的呼叫。

很显然,这是个非常严重的问题。我们推测这位“黑客”可能采用了发送大量SIP消息的方式来尝试上述分机的密码,并最终破解了密码。MSS以前的版本没有考虑这种异常情况,总是会允许SIP话机不停使用密码进行鉴权,直到最终通过鉴权为止,这就导致某些人刻意不停地扫描和尝试分机和密码。

为阻止这种情况,我们升级了MSS的版本,提供“失败则阻止(fail to ban, F2B)”特性。一旦SIP话机在一分钟内鉴权失败了若干次,则MSS会视之为“恶意扫描”并屏蔽其IP地址若干小时,期间MSS将拒绝所有来自该IP地址的SIP消息。这样迫使某些人几乎不可能破解SIP分机的密码。

F2B特性默认就开启,并且用户无需做任何配置。