Browsed by
Category: 版本Release

产品升级、Patch等相关信息发布

miniSIPPhone V26.1

miniSIPPhone V26.1

最近发布了 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 账号配置窗体

通常情况下SIP 服务器采用标准端口开放服务，用户确实没有必要了解协议规定的端口信息（我们访问互联网时也很少指定或者了解 80，443等端口），也没有必要去配置端口信息。因此我们删除了「服务器端口」配置项。

但是也存在 SIP 服务器采用非标准端口的情况（例如 miniSIPServer 云采用 6060 端口提供 SIP-TLS 接入，而不是标准定义的 5061 接口），新版本我们可以在「服务器地址」中一起指定地址和端口信息，例如：

15000.s2.minisipserver.com:6060

如果服务器提供的是 IPv6 地址和非标准端口，我们也可以采用以下示例的方式进行设置：

[fe80::5a11:22ff:fe74:8198]:6060
改进「基于 TLS 的 SIP」

改进「基于 TLS 的 SIP」

以前的 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」：

安全的企业 SIP 通信

安全的企业 SIP 通信

企业内部的通信系统一般部署在私网内部，在网络边缘部署 SBC 或者语音网关与外部进行通信，因此大部分场景下企业通信都很安全。然而越来越多的企业在云端部署 SIP 服务器，而企业内部的 SIP 终端也越来越多地从外部网络接入企业 SIP 服务器，这使得部分（或者全部）企业通信系统暴露在公共网络中，安全问题日益严重。

企业 SIP 通信安全涉及网络系统的许多方面，例如防火墙等。仅就 SIP 通信本身而言必须加密，避免将通信信息暴露给其他网络用户。加密的 SIP 通信包含两个部分：（1）SIP 消息（信令）加密，以及（2）语音流（RTP）加密，如下图所示：

SIP 加密通信网络拓扑

当然，企业可以部署 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 终端设备并不支持 DTLS-SRTP，如果需要部署，需要仔细检查终端的能力。

miniSIPServer 和 miniSIPPhone 默认可以选择 SRTP，无需额外的配置。部分 SIP 设备需要明确配置是否选择 SRTP，例如 MicroSIP 在配置账号时，「Media Encryption」需做以下设定：

MicroSIP 配置 SRTP
miniSIPPhone 支持 Linux 系统（Debian、Ubuntu）

miniSIPPhone 支持 Linux 系统（Debian、Ubuntu）

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
会议室以及其他

会议室以及其他

近日 miniSIPServer 升级到V60版本，这是最新的、可用于商业部署的稳定版本。第一个重大特性就是“会议室”业务，该业务支持不超过 5 个本地分机用户的会议呼叫。请参考业务文档了解细节。miniSIPServer 云也同步升级支持该业务。

另外，正如我们在前一篇博客中提到，V60 业务最终移除了部分老旧的业务，例如呼叫卡、话吧。这些业务曾经对我们某些特定的客户非常重要，但就目前而言该对这些业务说再见了。

ARM64 以及一些修改

ARM64 以及一些修改

正如大家所知，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++
安全问题

安全问题

OpenSSL 最近发布了新的版本用于修复若干严重的安全问题，而 miniSIPServer 是采用 OpenSSL 的库提供 “SIP over TLS”特性，因此我们也相应将 miniSIPServer 升级到最新的版本，即 V40 （20230221），该版本采用最新的 OpenSSL 库。

如果您在 VoIP 网络中部署了 “SIP over TLS”，我们强烈建议您将 miniSIPServer 升级到最新的版本。

Request-URI 的附加参数

Request-URI 的附加参数

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 附加参数”项，请参考下图：

Request-URI 附加参数配置
Request-URI 附加参数配置

ptime=20, 30, 40

ptime=20, 30, 40

在 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 数据包，然后尽力平滑语音的混音过程。另外，我们不得不指出，这显然增加了服务器的 工作负荷。

再见，Windows XP/2003

再见，Windows XP/2003

最近我们更新了 miniSIPServer 以适应 4K 分辨率显示屏的显示效果，但是我们发现，如果想获得非常完美的效果，必须同时升级我们现有的开发工具链。

然而新的工具链不再支持 Windows XP/2003 操作系统。这些操作系统非常棒，勤恳、可靠、任劳任怨，我们一直非常喜爱、信任这些老旧的系统。现在是时候道别了，我们将继续前行。

如果您是在 Windows 系统上部署 miniSIPServer，最新版本（V40）及后续版本将不再支持 Windows XP/2003 系统，最低要求为 Windows 7 （或以上）版本。我们也同步重新构建了 Debian / Ubuntu 系统上的版本，以适应高分辨率的显示需求。

请享受新版本吧。如果有任何问题、或者建议，欢迎您和我们联系。谢谢！