臨時響應的可靠性

眾所周知，RFC3262 協定定義了SIP臨時響應消息的可靠性。 這是個非常古早的特性，miniSIPServer（無論是本地版本，還是雲端版本）在很久以前就已經支持這個特性。 在與傳統電信運營商的IMS網絡對接時，往往必須要支持可靠的臨時響應消息，如果設備不具備此能力，運營商通常會直接拒絕所有的呼叫。

RFC3262定義了“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消息。

這不是一個很複雜的流程，我們一直都認為如此。 然而幾天前一比特雲通信用戶向我們反映，他無法呼叫外部電話。 我們跟踪了他的呼叫，得到以下圖描述的呼叫流程：

難以置信……這家VoIP運營商陞級系統後，在183消息中要求採用“100rel”能力確保臨時響應的可靠性，然而在miniSIPServer發送PRACK消息進行確認時，它居然返回“405 method not allowed”。 這種情況下當然會導致所有的外呼呼叫都失敗了。

這是為什麼？！ 如果不能接受、或者不支持 PRACK 消息，它為什麼在臨時響應消息（也就是183消息）中明確要求“100rel”呢？

要解决這個問題本來也相當簡單。 只要在臨時響應消息中移除“100rel”、即不要求可靠性保證即可，那樣miniSIPServer就不會發出PRACK消息。 但是不幸的是，這家運營商的團隊居然不知道該怎麼做。

我們的客戶就被耽擱在這了，他的業務被迫停滯下來。 另一方面，我個人猜測這家（以及某些）運營商採用了開源的服務器，例如Asterisk、FreeSwitch等，來構建自己的解決方案，但是他們也許沒有足够的專家來理解自己究竟構建了什麼。

囙此我們更新了miniSIPServer，在外線的配寘中新增一個選項用於關閉“100rel”能力，如下圖所示： 

一旦勾選了這項，miniSIPServer向外線發出INVITE消息時，將不會再攜帶“100rel”參數。 如果您對接了類似荒謬的運營商，請試試這個選項。