Browsed by
Tag: 临时响应

临时响应的可靠性

临时响应的可靠性

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

RFC3262与新版本

RFC3262与新版本

RFC3262定义了一种方法,用于SIP对话中传递可靠的临时响应消息。简单地说,就是定义了一个新的SIP消息“PRACK”用于响应“临时响应”消息(是不是很拗口?)。我们一直以来都觉得这不是个好想法,实际上多数传统的SIP设备都没有支持RFC3262定义的能力。

然后最近情况有些变化。在某些需要和传统PSTN网络互通的场景中,各设备必须具备RFC3262能力。尤其是在某些4G-IMS移动网络,例如中国市场的移动网络运营商,如果呼叫中没有指示支持RFC3262能力,网络会直接拒绝呼叫。

所以我们升级MSS到最新的V31版本,主要特性就是支持RFC3262能力。新版本的MSS会在呼出呼叫的消息中明确指示“100rel”,告诉对端设备或者SIP话机可以采用可靠的临时响应消息,这些设备自行决定是否要触发RFC3262的流程。在收到呼叫时,除非对端或者SIP话机明确要求RFC3262流程,否则默认情况下MSS不会主动发起RFC3262流程。这样可以确保同时兼容传统VoIP网络以及IMS网络。

本次升级对用户配置没有任何要求。如果您在部署MSS的过程中,遇到与PSTN网络或者移动IMS网络对接失败的情况时,可以考虑升级到最新的MSS试试。希望您能喜欢我们的软件!