Browsed by
Category: 版本Release

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

安全的企业 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 传输实现加密，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 协议。目前不支持 DTLS-SRTP，主要考虑以下几点：（1）SIP over TLS 已经可以确保 master key & salt 的安全性，与 DTLS 的作用等效；（2）虽然 WebRTC 等互联网技术广泛采用了 DTLS-SRTP，但大部分 SIP 设备并不支持 DTLS-SRTP，在企业 SIP 通信领域会有互联互通的问题。

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 系统上的版本，以适应高分辨率的显示需求。

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

适配 4K 屏幕

适配 4K 屏幕

最近有客户向我们报告了一个问题：miniSIPPhone 在 4K 屏幕中界面异常。如下图所示：

miniSIPPhone 界面异常
miniSIPPhone 异常界面

在构建图形界面（包括 miniSIPPhone 以及 miniSIPServer）时，我们采用绝对位置、长度来安排界面中的各个组件，因此如果屏幕具备很高的分辨率时（例如 4K 屏幕），绝对坐标值就显得非常小、甚至过于紧凑。

为了解决这个问题，我们将图形界面中的布局、组件全部换成相对坐标、相对尺寸。当然，同时修改、升级了 miniSIPPhone（V8.4） 以及 miniSIPServer（V39 build 20220823）。

另一方面，我们同时也修改了 miniSIPServer 对话框的尺寸、风格、以及布局，因此 miniSIPServer 的图形界面整体上更统一、更整齐，使用感受也会更舒服一些。

call tag 以及 cause

call tag 以及 cause

有时候客户希望知道一些历史呼叫的细节，例如哪一方释放的呼叫、为什么会释放呼叫等。由于这些细节都不是实时呼叫的细节，我们无法用 miniSIPServer 内部的跟踪工具进行跟踪，因此我们更新了 CDR 功能，以便回溯信息、了解呼叫的更深一点的细节。

在 CDR 的 FCI（Furnish Call/Charge Information, “提供呼叫/计费信息”）字段中，我们增加了参数“callTag=”以及”cause=”。请参考下图 CDR 记录的细节：

FCI 字段细节
FCI 字段细节

“callTag=” 参数用于保存当前呼叫的在 miniSIPServer 内部的释放位置，根据这个参数，我们可以知道呼叫在哪里被释放了、以及谁释放了这个呼叫。例如，呼叫有可能是收到了主叫侧的 BYE 消息从而导致释放的，诸如此类。这个参数的具体数值是 miniSIPServer 系统内部值，目前不会向客户们公开具体值的含义。

“cause=” 参数用于保存呼叫释放时的原因值。如果 miniSIPServer 收到了被叫侧的 4xx 或者 5xx 消息、同时该消息中包含 Reason 头域、并且在该域中携带了 cause 参数，则 miniSIPServer 会使用该原因值释放呼叫。其他情况下， miniSIPServer 根据内部的呼叫情况使用自己的 cause 值释放呼叫。当然，无论哪种情况， cause 值都会保存在 CDR 记录的 FCI 字段中。