Browsed by
Tag: SIP

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"
外线的 RequestURI 参数

外线的 RequestURI 参数

miniSIPServer 与 VoIP 服务器(网关)通过外线连接,发送消息(例如 REGISTER 或者 INVITE等消息)时会在 Request-URI 中自动附加参数“user=phone”。这是来自中国移动的要求。多数情况下这种做法都没有问题,在 RFC3261 规范中也明确定义了 RequestURI 的附加参数。

然而事情总有意外。最近有些客户向我们反映,miniSIPServer 与他们的 VoIP 服务商网络对接失败,对方服务器无法识别 RequestURI 的参数。当然,简单的方法自然是这些服务商升级自己的服务器,遵循 RFC3261 标准规范的定义,这样大家都会很舒适。

其中个别运营商坚持目前的状态,不愿意做出任何改变。那怎么办呢?我们不得不在外线的配置做出一点修改,请参考下图:

外线的 RequestUR 附加参数配置

我们在外线的“出呼叫”配置中,增加了一项“Request-URI 附加参数”。客户们可以根据自己的网络状况来设置该项的值。

需要说明的是,如果是中文界面,我们默认客户是在中国的网络环境下配置外线,因此该项的默认值是“user=phone“,而其他语种的界面中,该项默认为空。我们认为这样的处理可以满足全球各种网络环境的要求。

该修改已经应用于本地版本的 miniSIPServer 以及云端版本的 miniSIPServer,欢迎大家试用。

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

再见,Windows XP/2003

再见,Windows XP/2003

最近我们更新了 miniSIPServer 以适应 4K 分辨率显示屏的显示效果,但是我们发现,如果想获得非常完美的效果,必须同时升级我们现有的开发工具链。

然而新的工具链不再支持 Windows XP/2003 操作系统。这些操作系统非常棒,勤恳、可靠、任劳任怨,我们一直非常喜爱、信任这些老旧的系统。现在是时候道别了,我们将继续前行。

如果您是在 Windows 系统上部署 miniSIPServer,最新版本(V40)及后续版本将不再支持 Windows XP/2003 系统,最低要求为 Windows 7 (或以上)版本。我们也同步重新构建了 Debian / Ubuntu 系统上的版本,以适应高分辨率的显示需求。

请享受新版本吧。如果有任何问题、或者建议,欢迎您和我们联系。谢谢!

适配 4K 屏幕

适配 4K 屏幕

最近有客户向我们报告了一个问题:miniSIPPhone 在 4K 屏幕中界面异常。如下图所示:

miniSIPPhone 界面异常
miniSIPPhone 异常界面

在构建图形界面(包括 miniSIPPhone 以及 miniSIPServer)时,我们采用绝对位置、长度来安排界面中的各个组件,因此如果屏幕具备很高的分辨率时(例如 4K 屏幕),绝对坐标值就显得非常小、甚至过于紧凑。

为了解决这个问题,我们将图形界面中的布局、组件全部换成相对坐标、相对尺寸。当然,同时修改、升级了 miniSIPPhone(V8.4) 以及 miniSIPServer(V39 build 20220823)。

另一方面,我们同时也修改了 miniSIPServer 对话框的尺寸、风格、以及布局,因此 miniSIPServer 的图形界面整体上更统一、更整齐,使用感受也会更舒服一些。

“回呼”业务更新

“回呼”业务更新

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

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

免费版本

免费版本

今天我们增加了一个新的 miniSIPServer 版本(5 客户端版本),这是一个免费版本!您不需要注册码即可长期使用,也不用担心试用期过期的问题。

“5 客户端”版本特别适合微型的 VoIP 网络,例如家庭用户、测试等。您不需要付一分钱就能获得完整的 VoIP 功能特性,当然,SIP/VoIP 客户端数量被限制为不能超过5个。

另外,免费版本不能用于商业目的或者商业场景。

希望您能享受这个新的版本!

转发视频流

转发视频流

如果您使用以前版本的 miniSIPServer,如果想让 miniSIPServer 转发媒体流,miniSIPServer 只会转发语音流而去掉视频流。

这主要是因为视频流会占用太多的带宽,同时也要求服务器有足够的计算能力。很多设备实际上达不到这样的要求。但是越来越多的客户要求我们改进这点,在转发语音流的同时也转发视频流,因为他们的设备目前已经足够强大,而且网络也有足够的带宽。

既然如此,这个要求似乎非常合理,因此我们认为应当升级 miniSIPServer 满足这些客户的需求。

因此最新版本(20210604 构建版本)正式发布,这个版本在转发媒体流的时候,将同时转发语音流和视频流。

升级版本后无需更改配置,您唯一要注意的是硬件的计算能力和网络的带宽是否满足需求。