miniSIPServer

新版 miniSIPServer 允許用戶用瀏覽器（Chrome、Firefox、Edge等支援 WebRTC 技術的瀏覽器）發起呼叫，稍顯麻煩的是用戶必須自行部署 TLS/SSL 憑證以便 miniSIPServer 啟動 Websocket secure 服務並接收瀏覽器呼叫。 我們最近將這個特性移植到雲端虛擬 miniSIPServer。 更方便的是，用戶不需要關心證書問題，我們為虛擬 miniSIPServer 自動部署了 TLS/SSL 證書，用戶只要直接使用瀏覽器發起呼叫即可。 例如，我們在瀏覽器中使用類似以下的 URL 即可向自己的雲端 miniSIPServer 發起通話： https://www.myvoipapp.com/miniwebphone2/lite.html?server=15000.s2.minisipserver.com&clr=100&pwd=100&cld=101 其中 server 參數指定虛擬 miniSIPServer 的位址，目前僅支援後綴為 s2.minisipserver.com 的虛擬伺服器。 如果您的伺服器字尾是舊版的 s1.minisipserver.com，只能改到新伺服器才能支援 WebRTC 通話。 其他幾個參數：clr、pwd 和 cld 請 參考前一篇文件 的說明，本地 miniSIPServer 和雲端虛擬 miniSIPServer 的參數是一致的。 同樣，目前虛擬 miniSIPServer 也只接受來自 WebRTC 的呼叫，不支援從 SIP 網域向瀏覽器或 WebRTC 發起呼叫。            

新發布的 miniSIPServer （V70 build 20250402）支援一個很有趣的特性：我們可以用瀏覽器（必須支援 WebRTC 技術，例如 Chrome、Firefox 等）向 miniSIPServer 發起呼叫，呼叫 SIP 網域的裝置（電話、網關等）。 網路拓撲如下圖所示： 語音媒體串流採用端對端加密方式透過 DTLS-SRTP 傳遞，與 miniSIPServer 連結。 目前僅支援語音通話，不支援視訊通話。 瀏覽器 Web 側採用簡化版的訊號（MCCP，miniSIPServer Call Control Protocol，即 miniSIPServer 呼叫控制協定）控制呼叫，並透過加密的 Websocket 連線（ WSS，Websocket security）與 miniSIPServer 對接。 目前僅支援 Web 域向 SIP 域發起呼叫，不支援反向由 SIP 域向 Web 域發起呼叫。 我們在瀏覽器中輸入下列 URL 即可從瀏覽器向 SIP 網域發起通話（示範分機使用者100 呼叫分機使用者 101）： https://www.myvoipapp.com/miniwebphone2/lite.html?server=192.168.3.70&clr=100&pwd=100&cld=101 URL 類似命令列方式，其中各項參數說明如下： （1）「https://www.myvoipapp.com/miniwebphone2/lite.html」是一個簡單的頁面，加載到瀏覽器後即可與指定的 miniSIPServer 伺服器建立 WSS 連接，並發起呼叫。 我們可以將這個頁面及相關的資源都下載到本地或本地的 Web 伺服器，瀏覽器開啟本機檔案同樣也可以發起通話。   （2）「server」指定 miniSIPServer 的位址。 該 miniSIPServer 必須已經成功載入憑證和金鑰、並啟動了 WSS 服務。 miniSIPServer 預設總是採用 TCP 5062 連接埠啟動 WSS 。 （3）「clr」發起呼叫的主叫用戶號碼。 該號碼必須是 miniSIPServer 的分機用戶號碼。 （4）「pwd」主叫用戶用於鑑權的密碼，即 miniSIPServer 分機用戶的密碼。 miniSI...

在 SIP 通訊領域，keep-alive （保活）有兩種：設備的 keep-alive 與會話（session，dialog）的 keep-alive。 設備的 keep-alive 目前大家都有成熟統一的解決方案，並且符合 RFC3261 的要求，那就是採用 OPTIONS 操作進行檢測，如果對端設備返回 200OK 則說明設備 keep-alive。 終端採用 REGISTER 也可以偵測設備 keep-alive。 各廠商一直沒有會話 keep-alive 的統一解決方案。 RFC4028 規範雖然定義了 reINVITE 和 UPDATE 用於會話 keep-alive 檢測，但是這兩個操作用於會話檢測顯得太複雜了，會導致重新協商媒體，影響會話的通話品質。 目前各廠商的想法倒是基本一致：既然正常的 reINVITE 和 UPDATE 操作會導致新的媒體協商，那不攜帶 SDP 是不是就可以直接用於會話的 keep-alive？ 當然， reINVITE 是例外，「reINVITE without SDP」已經被用於 3PCC 流程，因此不可能再用於會話 keep-alive 操作。 我們根據歷年與各廠商設備對接的經驗，總結以下用於會話 keep-alive 的操作： UPDATE without SDP INFO without SDP MESSAGE without SDP 最新版本 miniSIPServer 的預設處理方式：如果在會話過程中收到上述三種 SIP 訊息，將進入會話 keep-alive 處理流程；如果會話存在，則傳回 200OK 訊息。 UPDATE 和 INFO 本身就只能在會話中傳遞，因此天然契合 keep-alive 的要求。 我們推薦優先採用 INFO，RFC3261 明確定義了 INFO，各廠商設備一定會支援 INFO 操作。 而 UPDATE 作業定義在補充協定中，部分廠商的設備未必會支援 UPDATE，更遑論 「 UPDATE without SDP 」 。     MESSAGE 即可以在會話內傳遞，也可以在會話外發起，用於傳遞即時訊息（instant message）。 我們限定  「 MESSAGE without SDP 」 只能在會話內傳遞，並保留給 keep-alive 流程處理。 ...

以前的 miniSIPServer 版本如果想啟動“SIP over TLS”，必須配置憑證和金鑰檔案（包括自簽章憑證和金鑰）。 如果在設定目錄中沒有這些文件，miniSIPServer 預設不會啟動 SIP over TLS。 大部分客戶部署「SIP over TLS」都採用自簽名憑證和金鑰。 Linux 系統自備 openssl 工具，很容易、也很方便建立這些文件，然而 windows 系統預設沒有 openssl 工具，客戶需要下載工具來建立憑證和金鑰，略顯麻煩。 為了簡化客戶的工作量，我們優化了 miniSIPServer 啟動「SIP over TLS」的一點步驟： miniSIPServer 預設總是啟動「SIP over TLS」。 如果配置了憑證和金鑰文件，則以客戶的憑證和金鑰加密 SIP 訊息；如果沒有設定憑證和金鑰文件，miniSIPServer 會自動建立自簽名憑證和金鑰加密 SIP。 因此，miniSIPServer 啟動時，我們能看到 TLS 連接埠訊息，這表示 miniSIPServer 啟動了「SIP over TLS」：          

我們通常只在 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) ，效果不錯：    歡迎大家試用！        

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

miniSIPPhone 終於升級到 V10 版本，此版本最重要的功能就是支援 Linux 系統。 當然，Linux 系統必須是 Debian 或 Ubuntu 系列的發行版本。 與 miniSIPServer 的要求一樣，Debian 版本要求是 V10（Buster）及以上版本，Ubuntu 版本要求是 V18.04（Bionic Beaver）及以上版本。 同時支援 X86_64 以及 ARM64（AArch64）兩種硬體架構。 現在在 Linux 系統上運行 SIP 電話非常簡單，請訪問我們的網站 下載 最新的版本： 例如，您下載的版本是“msp_v10_amd64.deb”，採用以下命令安裝： sudo dpkg --install msp_v10_amd64.deb 接下來就可以點選圖形介面快捷方式來運行 miniSIPPhone：   如果想要卸載 miniSIPPhone，則使用以下指令直接刪除即可： sudo apt remove minisipphone    

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

我們最近更新了 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 與 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 的組合。  

在 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 數據包，然後儘力平滑語音的混音過程。另外，我們不得不指出，這顯然增加了服務器的 工作負荷。