Browsed by
Category: How-to

一些简单的技术技巧,有助于您更有效地配置或者使用SIP服务器

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 附加参数配置

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”是个不错的选择。

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

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

外线配置

外线配置

部署VoIP网络时,我们常常会在miniSIPServer中配置外线连接VoIP运营商的服务器。考虑到市场中有大量的VoIP运营服务商,因此经常有客户咨询我们如果配置miniSIPServer来连接这些运营商的网络。

实际上在“小型企业建立IP-PBX系统指南”这篇指导文档中,我们已经提供了一个简单的外线配置,连接VoIP运营商“call centric”。您可以参考这篇文章了解VoIP网络和外线的相关细节。另一方面,我们在“常见问题”文档的“外线”章节,也给出了一些其他运营商的配置参考。如果您有兴趣或者需求的话,也可以参考这些文档,希望这些文档帮助您部署VoIP网络。

https://www.myvoipapp.com/cn/docs/faq/index.html

SIP中继转发媒体流

SIP中继转发媒体流

在某些VoIP网络部署中,我们需要采用“SIP中继”与其他VoIP服务器或者网关进行互联。在媒体处理方面,我们希望(1)本地分机之间的媒体流不经过MSS服务器,而(2)与其他VoIP服务器对接的呼叫中希望能通过MSS转发媒体流。

为解决这个需求,我们更新了V32版本,在“SIP中继”的“出呼叫”配置中,可以单独设置是否需要MSS来转发媒体。请参考下图:

SIP 中继转发媒体流配置
SIP 中继转发媒体流配置

请注意,目前仅支持转发语音流,不会转发视频流。

保存录制的语音

保存录制的语音

miniSIPServer 支持客户录制根据需要录制自己的语音,并替换系统默认的语音文件。以前的版本中,如果客户需要升级 MSS 的话,每次都需要备份好自己的语音,并重新替换系统默认的语音。

这当然是个小小的麻烦。现在,最新的V32可以解决这个麻烦了。

MSS 启动时,将在“mss_ann”目录下自动创建子目录“cust_ann”,现在您所有的自定义语音文件都可以放在这个子目录下。当 MSS 卸载或者升级时,这个子目录和内部的所有语音文件都不会删除或者被替换。MSS 启动后,会自动读取并加载“cust_ann”子目录下的语音文件。

在 windows 系统,这个子目录默认应该是“d:/myvoipapp/minisipserver/mss_ann/cust_ann”。在Linux系统中,这个子目录默认是“/opt/sipserver/mss_ann/cust_ann/”。

请参考在线文档了解录制自定义语音的更多细节。

https://www.myvoipapp.com/cn/docs/others/how_to_record_your_own_audio/index.html

连接Sonetel

连接Sonetel

“Sonetel.com”是一家VoIP运营商,提供各国本地电话号码服务。我们可以在MSS中添加外线,连接Sonetel的服务器。根据Sonetel给出的配置参考,有以下几方面的内容需要注意:

  • Sonetel采用用户的email地址作为SIP帐号,并且
  • 部署了Proxy(SBC)服务器统一处理外部SIP消息。

本文给出一个简单的示例,指导如何配置MSS与Sonetel互联。我们假设用户的SIP帐号是“abc@gmail.com”。

在MSS中,请点击菜单“数据 – 外线”,增加一条新记录。

配置Sonetel外线
配置Sonetel外线

在“基本配置”页中,外线类型是“连接到对端VoIP服务器”,用户名是“abc”,而“服务器地址/域”必须是“gmail.com”。

另外请注意,密码項应该是在注册sonetel帐号时的密码,而不是email帐号自身的密码。

由于sonetel前置了Proxy(SBC)来处理SIP消息,因此我们在外线中还需要指定这个Proxy地址。在“出呼叫”页面中,指定对应的服务器地址,如下图所示。

Sonetel代理服务器地址
Sonetel代理服务器地址

Sonetel代理服务器地址为“sip.sonetel.com”,在注册时sonetel发送的email邮件有相应的说明。如果未来有变动,参考sonetel邮件说明即可。

对接中国电信IMS网络

对接中国电信IMS网络

最近帮助一位客户部署MSS服务器,对接中国电信IMS网络。在本次对接中,中国电信的软交换是ZTE的设备(至少SIP消息中的User-Agent是这么描述的),存在一些问题,需要特别注意配置方法才能完成对接。

由于中国电信是提供账号、密码信息进行对接,因此在MSS中应配置“外线”,其中需要注意的是以下几个关键点:

鉴权用户

通常外线配置中,默认采用“外线/账户”做鉴权用户(或者配置单独的鉴权ID)。而ZTE设备要求采用完整的URI作为鉴权用户名,因此在MSS的外线配置中,必须配置“鉴权用户名应包含地址信息”项,请参考下图。

外线鉴权用户配置
外线鉴权用户配置

设置该项后,例如上图的信息,MSS将采用“+8612345678@gd.ctcims.cn”作为鉴权用户名进行鉴权操作。

如果不采用完整格式的鉴权用户名,IMS网络会返回“403 Forbidden”拒绝注册和呼叫。我们认为这实际是ZTE软交换的缺陷,因为鉴权信息中本来就携带了域信息,无论鉴权用户名是否携带域信息,应该都不影响鉴权。如果您在与其他IMS设备对接时,也遇到了类似的问题,建议试试上述配置項。

Proxy设置

在中国电信的IMS网络中,对外的服务器地址作为逻辑域存在,实际上并不可访问。例如,上述例子中的“gd.ctcims.cn”就是域,而不是实际的SIP服务器。SIP消息实际应路由到指定的物理实体(在此我们理解为IMS网络前置的一个SBC或者Proxy),因此在MSS外线配置中,必须指明实际SIP消息需要路由的地址,请参考下图:

IMS网关的物理地址
IMS网关的物理地址

阻止匿名呼叫

阻止匿名呼叫

我们可以使用“系统黑白名单”来过滤、阻止匿名呼叫。请点击菜单“业务 – 系统黑名单”,添加以下记录:

caller number prefix = anonymous
called number prefix = *
rate = 100

该记录的作用就是:100%阻断来自“anonymous”的呼叫。

有些匿名呼叫的主叫号码可能会有差别,不过仍然可以在“系统黑名单”配置类似的记录进行过滤。

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。