miniSIPServer

在 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 流程處理。 ...

最近發布了 miniSIPPhone V26.1 版本，這個版本主要包含以下關鍵特性或修改： 一、支援 DTLS-SRTP miniSIPServer 支援 DTLS-SRTP 之後，我們更新了 miniSIPPhone， 使其也可以過 DTLS-SRTP 加密傳輸語音流。 我們在部署企業通訊網路時（尤其是涉及在外部公有雲系統部署）完全實現訊號、媒體高強度的加密，確保企業通訊安全。 在 miniSIPServer 和 miniSIPPhone 我們統一對 DTLS-SRTP 做出以下限制： （1）DTLS 必須是 DTLSv1.2 以上版本，不支援低於 v1.2 版本的握手協商。 （2）加密套件固定為 SRTP_AES128_CM_SHA1_80。 規格中定義了若干個加密套件，我們採用最高強度的加密，不支援協商其他加密套件。 （3）fingerprint 總是採用 SHA-256 編碼，不支援 SHA-1 或其他的編碼方式。 二、簡化帳號配置 新版本在配置 SIP 帳號時，不再需要單獨的配置來指定 連接埠 ，如下圖所示： 通常情況下SIP 伺服器採用標準連接埠開放服務，使用者確實沒有必要了解協定規定的連接埠資訊（我們存取網際網路時也很少指定或了解 80，443等連接埠），也沒有必要去設定連接埠資訊。 因此我們刪除了“伺服器連接埠”配置項目。 但也存在 SIP 伺服器採用非標準連接埠的情況（例如 miniSIPServer 雲採用 6060 連接埠提供 SIP-TLS 接入，而不是標準定義的 5061  連接埠 ），新版本我們可以在「伺服器位址」中一起指定位址和連接埠資訊，例如： 15000.s2.minisipserver.com:6060 如果伺服器提供的是 IPv6 位址和非標準 連接埠 ，我們也可以採用以下範例的方式進行設定： [fe80::5a11:22ff:fe74:8198]:6060                          

以前的 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) ，效果不錯：    歡迎大家試用！        

「連選組」是一項非常古老的企業通訊業務，在電路電話時代就有廣泛的應用， 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...

miniSIPServer 雲端可讓使用者定義自己的 IVR-XML 檔案以及相關的語音文件，以滿足使用者自己公司 IVR 業務的特定要求。 但是這些文件需要發送給我們的支援團隊，幫助上傳到使用者的虛擬伺服器。 這確實有點繁瑣，也非常不方便。 因此我們最近更新了雲端系統，允許用戶自己上傳 IVR-XML檔案以及語音檔案到虛擬伺服器。 請點選選單「帳戶 – IVR-XML 檔案（或語音檔案）」完成操作即可。 當然， IVR-XML 檔案必須遵循 IVR-XML 技術規範 的要求，而語音檔案也必須符合 miniSIPServer 語音編碼 要求。        

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

是的，我們又升級 miniSIPPhone了！ miniSIPPhone V10.10 現在可以支援 SIP over TCP/TLS。 在 SIP 帳戶的設定中新增了「傳輸」一項，用於指定採用哪種傳輸方式連接 SIP 伺服器： 如果採用 SIP over TLS，那麼所有的 SIP 訊息都是加密傳輸。 如果企業通訊系統中的設備（分機或伺服器）是部署在公共網絡，那就非常有必要對通訊內容進行加密保護。 我們知道雲端 miniSIPServer 系統支援 SIP over TLS，而且雲端系統都部署在公有網路中，因此如果客戶端同時部署 miniSIPPhone 的話，整個企業 VoIP 系統顯然會更安全。 當然，miniSIPPhone 也可以與其他支援 SIP over TCP/TLS 的伺服器（或 PBX ）一起工作，共同建立完整、安全的企業通訊系統。        

今天我們發布了最新版本的 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 發起的呼叫。