miniSIPServer

 

（原文鏈接：請 點擊這裏 。） 如大家所知，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 的組合。  

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

OpenSSL 最近發布了新的版本用於修復若干嚴重的安全問題，而 miniSIPServer 是採用 OpenSSL 的庫提供 “SIP over TLS”特性，因此我們也相應將 miniSIPServer 升級到最新的版本，即 V40 （20230221），該版本採用最新的 OpenSSL 庫。 如果您在 VoIP 網絡中部署了 “SIP over TLS”，我們強烈建議您將 miniSIPServer 升級到最新的版本。

SIP網絡默認採用SIP URI傳遞資訊，例如From、To等消息頭，格式如下： sip:+8613901088888@ims.bj.chinamobile.com 傳統的電信網路一般都是採用E.164格式的電話號碼，這種格式與SIP URI有很大差別，囙此ETSI（3GPP）定義了一種新的URI，即TEL URI，格式如下： tel:+8613901088888 因此在連接電信運營商的 IMS 網絡時，通常可能有兩種 URI 格式： SIP URI 以及 TEL URI。 miniSIPServer 可以支持這兩種格式，能夠自動處理入呼叫的 TEL URI 格式，但是 miniSIPServer 自己在發出呼叫時，總是採用 SIP URI 格式。 這裡有一點問題。幸運的是 IMS 網絡考慮非常仔細，例如中國移動可以接受 TEL URI 以及帶有特殊參數“user=phone“ 的 SIP URI，格式如下： sip:+8613901088888@ims.bj.chinamobile.com; user=phone 如果我們配置”外線”連接中國移動的網絡，事情就很順利，因為 miniSIPServer 在外線的呼叫中會自動給 Request-URI 添加“user=phone”。但是在某些市場（區域），中國移動要求採用 SIP 中繼的連接方式，這就會導致問題。 miniSIPServer 在中繼呼叫中不會對 Request-URI 添加上述參數，因為這種場景我們認為是“服務器 對 服務器”的模式。 為了解決這個問題，我們在 SIP 中繼的“出呼叫”配置中增加了“Request-URI 附加參數”項，請參考下圖：      

眾所周知，RFC3262 協定定義了SIP臨時響應消息的可靠性。 這是個非常古早的特性，miniSIPServer（無論是本地版本，還是雲端版本）在很久以前就已經支持這個特性。 在與傳統電信運營商的IMS網絡對接時，往往必須要支持可靠的臨時響應消息，如果設備不具備此能力，運營商通常會直接拒絕所有的呼叫。 RFC3262定義了“100rel”參數來訓示臨時響應消息的可靠性，囙此我們在此將其稱為“100rel”能力。 通常情况下，主叫在發起呼叫時應明確訓示出自己是否支持“100rel”能力，被叫也同樣需要明確 要求 採用“100rel”能力，囙此呼叫雙方才能建立臨時響應消息的可靠性。  在RFC3262標準中，我們可以明確以下細節： …… the initial request contained a Supported or Require header field listing 100rel, and that there is a provisional response to be sent reliably. …… UAS core … MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field. 上圖描述了可靠臨時響應消息的基本流程。 UAC在收到可靠的臨時響應18x消息時，應當向UAS方發送PRACK消息，告訴UAS自己已經收到了18x消息。 這不是一個很複雜的流程，我們一直都認為如此。 然而幾天前一比特雲通信用戶向我們反映，他無法呼叫外部電話。 我們跟踪了他的呼叫，得到以下圖描述的呼叫流程： 難以置信……這家VoIP運營商陞級系統後，在183消息中要求採用“100rel”能力確保臨時響應的可靠性，然而在miniSIPServer發送PRACK消息進行確認時，它居然返回“405 method not allowed”。 這種情況下當然會導致所有的外呼呼叫都失敗了。 這是為什麼？！ 如果不能接受、或者不支持 PRACK 消息，它為什麼在臨時響應消息（也就是183消息）中明確 要求 “100rel”呢？ 要解决這個問題本來也相當簡單。 只要在臨時響應消息中移除“100rel”、即不要求可靠性保證即可，

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