miniSIPServer

近日 miniSIPServer 升級到V60版本，這是最新的、可用於商業部署的穩定版本。 第一個重大特色就是「會議室」業務，該業務支援不超過 5 個本地分機用戶的會議呼叫。 請參考業務文件了解細節。 miniSIPServer 雲端也同步升級支援該業務。 另外，正如我們在前一篇部落格中提到，V60 業務最終移除了部分老舊的業務，例如呼叫卡、話吧。 這些業務曾經對我們某些特定的客戶非常重要，但就目前而言該對這些業務說再見了。  

大約 20 年前我們開發並發布了 miniSIPServer，期間我們為越來越多的客戶加入了非常多的功能和業務。 最近我們重新檢視了 miniSIPServer 的所有業務。 其中有些業務的歷史非常悠久，我們判定這些業務可能已經無法適應目前的環境（或者說在當前環境下已經沒有實用意義），例如「話吧」、「呼叫卡」等各類業務。 下一個版本將優化（或清除）這類老舊的業務，miniSIPServer 將步入新的階段，將變得更快、更穩定、更適合新的 VoIP 網路需求。    

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

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

我們最近更新了 miniSIPServer 以支援 TLSv1.3。 本次修改不影響配置，如果您升級 miniSIPServer 到最新版本，無需修改任何配置。 miniSIPServer 有兩個模組有可能用到 TLSv1.3：（1）SIP 伺服器模組；以及（2）嵌入式 HTTP 伺服器模組。 如果您的 SIP 話機（或軟體電話）支援 TLSv1.3，那麼採用此協定將能更好地保護您的通訊。 請參考《 基於 TLS 的 SIP 》以了解更多細節。 目前本地 miniSIPServer 和雲端 miniSIPServer 都可以支援基於 TLSv1.3的 SIP 通訊。   本機 miniSIPServer 採用內嵌式 HTTP 伺服器提供 web 管理，預設沒有加密。 如果您需要或希望透過公共網路管理、設定 miniSIPServer，那麼建議啟用加密傳輸的 HTTP 服務。 目前主流的瀏覽器，例如Chrome、Edge、Firefox 等，都支援 TLSv1.3，請參考《 Web 管理 》配置和啟用加密的HTTP。  

 

（原文鏈接：請 點擊這裏 。） 如大家所知，miniSIPServer有一些專門為樹莓派（Raspberry Pi）訂製的版本，這些版本都是基於 armhf 架構。 最近越來越多的客戶向我們諮詢在 arm 系統上運行的 miniSIPServer，經調查，大部分都是 arm64 架構的伺服器或板載系統。 據此我們將為特定的樹莓派系統定制的 miniSIPServer 修改為普適性的、基於 ARM64 架構的 miniSIPServer。 當然，樹莓派也支援 arm64 架構，因此這次的修改基本上能涵蓋大部分的 arm 架構應用場景。 另一方面，這些應用場景的大部分客戶都只需要命令列方式的 miniSIPServer，他們並不需要圖形介面的 miniSIPServer，也就是說他們只需要執行 minisipserver-cli 就可以了。 預設情況下， miniSIPServer 安裝套件會要求安裝qtbase5-dev 庫以支援圖形介面，而此類場景中實際上已經不需要這個函式庫了，因此我們修改了miniSIPServer 安裝套件的deb-control 控制參數，將qtbase5-dev 包從'Depends'段改到'Suggests'段。 如果您希望執行圖形介面的 miniSIPServer，則需要用以下命令安裝依賴函式庫： sudo apt install gcc g++ qtbase5-dev 如果您只是希望執行命令列方式的 miniSIPServer， 則需要以下命令安裝相依性庫：   sudo apt install gcc g++          

 （原文：請 點擊鏈接 。） 「呼叫前轉」是 VoIP 以及通訊領域非常傳統的業務。 預設一般是由 SIP 終端機（話機）發送 3xx 訊息給 miniSIPServer 進行呼叫前轉，當然 miniSIPServer 本身也可以直接發起呼叫前轉。 大多數情況下，主叫側並不知道被叫側發生了呼叫前轉，主叫側也不關心被叫側的呼叫是否被前轉了。 然而，有些時候主叫側確實需要知道被叫側的呼叫前轉。 miniSIPServer 目前會向主叫側發送 181 Call Is Being Forwarded 訊息，明確告知主叫：被叫側正發生呼叫前轉。 在 181 訊息中，miniSIPServer 增加了一個 Call-Info 頭域攜帶前轉的必要資訊。 請參考下圖： 上圖的流程發生了兩次前轉：（1）被叫 B 被前轉到被叫 C；以及（2）被叫 C 被前轉到被叫 D。    181 消息的 Call-Info 头域将携带以下信息：（1）呼叫正在被前转；（2）谁发生了呼叫前转；以及（3）前转呼叫的目标用户。请参考上图第一个 181 消息（即被叫 B 前转到被叫 C）中的 Call-Info 头域细节： Call-Info: purpose=forwarding, username="userb", contact="userc"  

（原文：請點擊 鏈接 。） 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 的組合。