Debian 以及 Ubuntu 版本支援問題

最新的 miniSIPServer V60版本發布後，對 Debian 以及 Ubuntu 的版本支援做出了修改。 Debian 最低版本要求是 oldoldstable 版本，即目前的 V10 版本，也就是說 miniSIPServer 後續將不再支援 Debian V8、V9等版本。

考慮到 Ubuntu 實際是基於 Debian 的系統，因此相應的最低版本要求變更為 Ubuntu V18.04。

請參考線上文件以了解 miniSIPServer 對 Linux 系統的最低要求及相關細節。  

留言

發佈留言

此網誌的熱門文章

外線的 RequestURI 參數

圖片
（原文：請點擊 鏈接 。） miniSIPServer 與 VoIP 服務器（網關）通過外線連接，發送消息（例如 REGISTER 或者 INVITE等消息）時會在 Request-URI 中自動附加參數“user=phone”。這是來自中國移動的要求。多數情況下這種做法都沒有問題，在 RFC3261 規範中也明確定義了 RequestURI 的附加參數。 然而事情總有意外。最近有些客戶向我們反映，miniSIPServer 與他們的 VoIP 服務商網絡對接失敗，對方服務器無法識別 RequestURI 的參數。當然，簡單的方法自然是這些服務商升級自己的服務器，遵循 RFC3261 標準規範的定義，這樣大家都會很舒適。 其中個別運營商堅持目前的狀態，不願意做出任何改變。那怎麼辦呢？我們不得不在外線的配置做出一點修改，請參考下圖： 我們在外線的“出呼叫”配置中，增加了一項“Request-URI 附加參數”。客戶們可以根據自己的網絡狀況來設置該項的值。 需要說明的是，如果是中文界面，我們默認客戶是在中國的網絡環境下配置外線，因此該項的默認值是“user=phone“，而其他語種的界面中，該項默認為空。我們認為這樣的處理可以滿足全球各種網絡環境的要求。 該修改已經應用於本地版本的 miniSIPServer 以及雲端版本的 miniSIPServer，歡迎大家試用。        
Read more »

如果您需要部署 FXS 網關，……

圖片
FXS（Foreign Exchange State，外部交換站）網關用於將傳統電話設備連入 VoIP 網域，一般網路拓樸如下所示： VoIP 域 <--> miniSIPServer <--> FXS 网关 <--> 传统电话 一般一台 FXS  網關 連接一通傳統電話，但有些 FXS  網關 也能同時接上多台傳統電話，此時需要特別注意。 FXS  網關 連接多台傳統電話時，需要多個 SIP 分機帳號對應接取 miniSIPServer。 另外，網關有可能採用一個位址（IP 位址+端口）與 miniSIPServer 建立連線、註冊分機帳號。 這也就是說，多個分機帳號會採用同一個位址。 如果網關內某個帳號設定錯誤，網關會不停用錯誤訊息向 miniSIPServer 註冊，此時會觸發“失敗則阻止”，miniSIPServer 會屏蔽掉該網關的位址。 如前所述，網關內的 SIP 帳號都採用了同一個位址，因此這實際上會導致其他帳號同時註冊失敗。 在這種情況下，我們需要為該網關關閉“失敗則阻止”，即將網關的位址加入白名單。 請點選選單“業務 – IP位址黑白名單”，增加記錄接受網關的IP位址。 如下圖所示：    
Read more »

臨時響應的可靠性

圖片
眾所周知，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”、即不要求可靠性保...
Read more »