miniSIPServer

我們通常只在 Debian、Ubuntu 系統上開發和發布適用於 Linux 系統的 miniSIPServer 軟體，預設採用 deb 安裝套件發布版本。 如果使用者是 Linux 宇宙另一個派系－RPM派，要部署 miniSIPServer 就不太方便。 越來越多的客戶希望 miniSIPServer  能 部署在 SUSE、Fedora、openEuler 等作業系統上。   考慮到我們沒有充足的資源（包括人力、設備等），我們決定發布 AppImage 格式的安裝包，這樣幾乎可以適應所有非 Debian 系列的 Linux 系統。 當然，目前僅適配 X86_64 (AMD64) 架構，暫時沒有適合 ARM64 架構。 請從網站 下載 對應的版本： 使用非常簡單，甚至無需安裝。 將下載的 miniSIPServer 軟體（例如 minisipserver_u500.AppImage）儲存在任何目錄下，然後設定「可執行權限」： chmod +x minisipserver_u500.AppImage 雙擊該檔案或在命令列下直接運行該檔案即可：   ./minisipserver_u500.AppImage  其他與安裝 deb 套件的方式是一樣的。 設定檔也都保存在 $HOME/.minisipserver 目錄下。   我們分別測試了 openSUSE（Leap 16）、Fedora 42 以及 openEuler (24.03 LTS SP2) ，效果不錯：    歡迎大家試用！        

「連選組」是一項非常古老的企業通訊業務，在電路電話時代就有廣泛的應用， VoIP 時代也仍有大量的企業部署該業務。 然而時代畢竟變了，業務本身也需要與時俱進，適應 IP 網路的特色和要求。 我們依據最近客戶的需求和網路環境的變化，對 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...

Debian 13 (Trixie) 昨天發布了。 這個版本是最新的穩定版本，非常適合商業部署。 我們是 Debian 系統的忠誠粉絲，第一時間在該系統上安裝、測試了 miniSIPServer。 所有的測試案例都通過了，結果很完美！ 您可以在 Trixie  系統 上部署商用企業通訊環境，這絕對是令人興奮的選擇！    

今天我們發布了最新版本的 miniSIPPhone（一款小巧的、適合企業通訊的軟體電話），主要包含了兩個新功能：（1）通訊錄，以及（2）即時訊息。 miniSIPPhone 用一個新的窗體來建立、管理通訊人清單： 在通訊錄中，您可以選擇一個目標用戶，然後雙擊（或按「C」鍵、或點擊「呼叫」按鈕）發起呼叫。 若希望發送即時訊息，選擇目標使用者後按下「M」鍵（或點選「發送訊息」按鈕），顯示即時通訊窗體發送訊息： 每個使用者對應一個獨立的即時訊息會話窗體。 每個窗體包含三個區域：（1）訊息顯示區域。 本區域顯示會話中的所有即時訊息，包括傳送的訊息和接收的訊息。 （2）輸入區域。 在該區域中可以輸入訊息的內容，然後按下「Ctrl+Enter」鍵發送訊息。 （3）「發送」按鈕，當然也是發送訊息。 miniSIPPhone 使用 SIP-MESSAGE 操作發送和接收即時訊息，目前僅支援純文字訊息，也就是不支援：圖片、檔案、語音以及視訊等內容。 當然，miniSIPPhone依然能夠運作在 Windows 和 Linux 系統（包括 AMD64 和 ARM64 架構）。 實際上，上圖中的兩個軟終端機就運行在不同的系統上。 希望您能喜歡 miniSIPPhone！ :-)        

眾所周知 VoIP 域（SIP域）採用 SIP URI 建立呼叫對話。 如果需要連接傳統的 PSTN 電話網絡，我們需要部署 VoIP 網關（或 SBC 會話邊界控制器）用於橋接兩個不同的網路。 大部分 網關 都支援 SIP URI，因此我們採用 SIP 中繼連接 SIP-PSTN 網路時，與連接 SIP-SIP 網路並沒有什麼不同。 但有些 網關 並不支援 SIP URI，它們僅能支援傳統電話號碼格式的URI（RFC3966規範定義了這種 TEL URI格式）。 這種 TEL URI 採用<tel:xxx>格式，而非<sip:name@address>格式。 請參考下圖： 先前版本的 miniSIPServer 總是能接受對方發起的 TEL URI 格式的呼叫，但是 miniSIPServer 本身並不會發起這種格式的呼叫。 最近幾個月先後有幾位客戶向我們反饋，希望 miniSIPServer 能支援採用 TEL URI 格式發起SIP 中繼呼叫，以便和傳統 PSTN 網路的網關進行對接，因此我們升級了 miniSIPServer （V60 build 20250208）擴展 SIP 中繼的功能。 在 SIP中繼的“出呼叫”配置中，可以選擇“採用電話號碼格式”，miniSIPServer 據此將採用<tel> 格式發起呼叫，如下圖配置所示： 對於 SIP 中繼的入呼叫，無需任何改變，miniSIPServer 可以接受對方採用 SIP URI 或 TEL URI 發起的呼叫。

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

在 SIP 會話中， 我們常常在 SDP 中設置 ptime 參數，用於指示呼叫的雙方協商 RTP 數據包的大小。如果呼叫中的一方對 RTP 數據包的大小有不同的看法， 它可以在呼叫中設置自己期望的 ptime 參數。但是世界是如此的多樣而復雜，有一些 SIP 設備根本就不關心 ptime 參數，並且它們也根本不會告訴呼叫的另一方自己期望的 ptime 參數，往往就是直接開始發送 RTP 包。這種做法就極可能導致問題。 比如，“ 呼叫記錄 ”業務要求 miniSIPServer 混合從呼叫雙方收到的語音流。為了讓工作輕鬆、簡單，miniSIPServer 會設置 ptime 參數為20，也就是要求呼叫的雙方每20毫秒發送一個 RTP 數據包，因此 miniSIPServer 每20毫秒從雙方獲得數據包並進行混音、保存在本地文件中。讓人毫不意外的是，有些 SIP 設備每30毫秒發送一個包、有些設備每40毫秒發送一個包。當 miniSIPServer 拿到這些大小不一的包進行混音時，時間不一致、大小不一致，有些數據就不得不丟棄。這就導致最後混音的本地語音文件語音質量欠佳。 當然，理想的解決方案是各家設備都尊重 ptime 參數，但是我們對此毫不指望。 因此不得不升級 miniSIPServer 至 V40（build 20220922）來解決這個問題。新版本試圖緩存從呼叫雙方獲得的 RTP 數據包，然後儘力平滑語音的混音過程。另外，我們不得不指出，這顯然增加了服務器的 工作負荷。