miniSIPServer

企業內部的通訊系統一般部署在私網內部，在網路邊緣部署 SBC 或語音閘道與外部進行通信，因此大部分場景下企業通訊都很安全。 然而越來越多的企業在雲端部署 SIP 伺服器，而企業內部的 SIP 終端也越來越多地從外部網路連接到企業 SIP 伺服器，這使得部分（或全部）企業通訊系統暴露在公共網路中，安全問題日益嚴重。 企業 SIP 通訊安全涉及網路系統的許多方面，例如防火牆等。 僅就 SIP 通訊本身而言必須加密，避免將通訊資訊暴露給其他網路使用者。 加密的 SIP 通訊包含兩個部分：（1）SIP 訊息（訊號）加密，以及（2）語音流（RTP）加密，如下圖所示： 當然，企業可以部署 VPN 將整個網路系統（不僅是通訊系統，也包括辦公系統等）進行加密，加密的 SIP 通訊也可以建立在 VPN 之上。 建立企業 VPN 成本比較高、系統較複雜，本文僅討論加密的 SIP 通信，不涉及VPN 等其他網路安全技術。 SIP 訊息的加密透過「SIP over TLS」實現，雲端 miniSIPServer、本地 miniSIPServer 以及 miniSIPPhone 都支援 SIP over TLSv1.2 / TLSv1.3。 請參考 線上文檔 ，本文不再贅述。         語音流透過 SRTP  （或 DTLS-SRTP） 傳輸實現加密，SRTP 的 master key 和 master salt 透過 SIP 訊息的 SDP （ RFC4568 ）傳輸、協商，因此 SIP 訊息加密才能確保 SRTP 的關鍵資訊不會洩露，僅僅 SRTP 傳輸加密語音流、但是明文傳遞 SIP 訊息，不能確保整個 SIP 傳輸的安全性。   RFC4568 中定義了幾種加密套件，目前我們選擇支援預設的 AES_CM_128_HMAC_SHA1_80 ，暫不支援其他加密套件。   SRTP 協定族包含諸多擴展，目前 miniSIPServer 和 miniSIPPhone 支援最基礎的 RFC3711 協定，這也是絕大多數 SIP 設備（包括伺服器、PBX、SBC 以及終端）都支援的基礎 SRTP 協定。 同時也支援 RFC5763 ， 也就是支援 DTLS-SRTP——目前市面上有許多 SIP 終端設備並不支援 DT...

Ubuntu 24.04 是最新的 LTS（長期支援）版本，顯然在商業環境中將會有廣泛的部署。 我們安裝了這個重要的版本，並執行 miniSIPServer 進行了一些測試。 測試結果非常不錯，運行介面如下圖所示： 如果您希望在 Linux 環境中部署新的 VoIP 系統，那麼 Ubuntu 24.04 是個不錯的選擇。 請參考 線上文件 以了解如何在 Linux 系統部署 miniSIPServer 的更多細節。  

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

（原文：請 點擊鏈接 。） 最近一位 miniSIPServer 云通信系統客戶報告了一個問題，他的 SIP 電話全部都離線了，無法註冊到虛擬服務器。我們檢查了網絡和對應的虛擬節點，結果一無所獲。 我們試圖跟踪來自該用戶分機的 SIP 消息，但同樣跟踪不到任何消息。這說明來自客戶側的 SIP 消息都丟失了，但是測試表明他的本地網絡很正常，其他網絡應用都沒有問題，唯獨 SIP 網絡宕機了。 這確實非常奇怪。最終客戶發現他本地的 DNS 記錄由於不可知的原因被修改了，本地 ISP 對虛擬服務器的 DNS 查詢記錄返回了錯誤的地址。將 DNS 服務器配置為 Google 的 DNS 服務器地址後，問題解決，他的 VoIP 網絡回歸正常。 如果您的所有 SIP 電話都離線了，同時又發現網絡是正常工作狀態，您可以試試檢查 DNS 記錄。我們建議以下小技巧對比檢查本地 ISP 的 DNS 記錄與Google DNS 記錄。 如果您的工作系統是 Windows 系統，可以使用 nslookup 命令檢查 DNS 結果。例如，我們指定通過 Google 的 DNS 服務器（即‘8.8.8.8’）查詢虛擬服務器‘1425.s1.minisipserver.com’的 DNS 記錄，命令如下所示： nslookup 1425.s1.minisipserver.com 8.8.8.8 如果您的工作系統是 Linux 系統，可以使用 dig 命令查詢 DNS 結果，如下所示： dig @8.8.8.8 1425.s1.minisipserver.com  您可以按照上述方法再检查本地 ISP 的 DNS 结果。如果结果与 Google 的 DNS 结果不一致，那说明（1）您本地的 ISP 屏蔽了我们的云通信系统，或者（2）本地 ISP 的 DNS 记录由于不可知的原因被污染了。     我們推薦在 VoIP 網絡環境中採用 Google DNS 服務器（地址是 8.8.8.8），或者 Cloudflare DNS 服務器（地址是 1.1.1.1）。 另外，Debian 系統默認沒有 dig 命令，您需要安裝 dnsutils 包獲得該工具： sudo apt install dnsutils           ...

（ 原文：請 點擊鏈接 。 ） 最近 Debian 發布了最新的 V12 版本，即 Bookworm 版本。毫無疑問這是最新的穩定版本，也是商業環境中將會大量部署的版本，因此我們一如既往地在該版本中運行、測試了我們最新的 miniSIPServer 版本，驗證結果也是一如既往的完美！如下圖所示： 如果您是在 Linux 系統中部署 VoIP，您可以選擇 Debian 12 系統。請參考我們的 指導文檔 了解如何在 Linux 系統中安裝、運行 miniSIPServer。相信您會喜歡 Debian + miniSIPServer 的組合。  

（原文：請 點擊鏈接 。） 我們最近更新了 miniSIPServer 產品的 web 管理界面，包括本地 miniSIPServer 產品以及雲端 miniSIPServer。新界面更接近本地 miniSIPServer 的圖形管理界面，請參考下圖： 我們希望新界面能幫助已經熟悉本地圖形界面的 miniSIPServer 用戶，這些用戶在面對“熟悉”的界面時能快速體驗雲端 miniSIPServer。