在 Ubuntu 24.04 （Noble Numbat）系統中執行 miniSIPServer

Ubuntu 24.04 是最新的 LTS（長期支援）版本，顯然在商業環境中將會有廣泛的部署。 我們安裝了這個重要的版本，並執行 miniSIPServer 進行了一些測試。 測試結果非常不錯，運行介面如下圖所示：

Run miniSIPServer on Ubuntu 24.04

如果您希望在 Linux 環境中部署新的 VoIP 系統，那麼 Ubuntu 24.04 是個不錯的選擇。

請參考線上文件以了解如何在 Linux 系統部署 miniSIPServer 的更多細節。 

留言

發佈留言

此網誌的熱門文章

外線的 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 »