我们最近发布了一款小软件：miniDNServer （简称 MDNS），主要满足与域名解析相关的两个需求：
（1） 我们希望为内网的各种计算设备提供域名访问方式，从而增强网络部署的灵活性。比如公司内部的 NAS 服务器，可以设置成域名「nas.local」访问。MDNS 通过 「DNS over UDP， DoU」 方式为内网各种设备提供 DNS 服务。
（2）考虑到公网环境的恶劣程度，我们希望在访问外部域名时，能采用加密方式访问公共 DNS 服务器，避免对 DNS 结果的各种干扰。也就是说，MDNS 可以转发内网设备对外网域名的 DNS 请求，并采用 「DNS over TLS，DoT」方式访问公共 DoT 服务器解析域名。
下图描述了 MDNS 工作模式的网络拓扑：
MDNS 在我们自己的环境中已经应用了一段时间，效果很好，我们自己也很满意。您在部署中小企业网络环境时，也可以考虑试试这款简单易用的 DNS 软件。
Let’s Encrypt 证书（以下简称 「Lets证书」）默认采用 PEM 格式，因此完全可以用于启动 SIP-over-TLS。
只需要将 Lets 的证书文件链接为「server.crt」、将 Lets 的密钥文件链接为「server.key」即可。 例如， Lets 签名「demo.com」的证书和密钥为以下文件：
/etc/letsencrypt/live/demo.com/fullchain.pem
/etc/letsencrypt/live/demo.com/privkey.pem
创建以下符号链接：
ln -sf /etc/letsencrypt/live/demo.com/fullchain.pem $HOME/.minisipserver/siptlsCert/server.crt
ln -sf /etc/letsencrypt/live/demo.com/privkey.pem $HOME/.minisipserver/siptlsCert/server.key
重启 miniSIPServer 后，即可采用 Let’s Encrypt 的证书和密钥启动 SIP-over-TLS。
Ubuntu 26.04 版本发布了，这是最新的 LTS 版本，显然也是一个非常重要的版本。我们在第一时间安装了这个系统，并运行 miniSIPServer 进行了一些基础测试。测试结果很不错，程序运行界面如下：
如果是部署一个新的 VoIP 系统，采用 Ubuntu 26.04 是个相当不错的选择。如果是升级现有系统，那建议还是暂缓一段时间，Ubuntu 26.04 是个重大升级版本，较旧版本有较大改动，建议进行更全面的测试后再决定是否升级。
新版 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 secure）与 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 分机用户的密码。miniSIPServer 用「号码+密码」对呼叫进行鉴权，只有鉴权通过的呼叫才允许接入，否则 miniSIPServer 会直接拒绝呼叫。
（5）「cld」呼叫的被叫号码，可以是本地分机号码，也可以是外呼号码。
语音流通过 DTLS-SRTP 传输，采用端对端协商和加密，miniSIPServer 无需对媒体进行额外配置。
miniSIPServer 仅需要配置证书和密钥启动 WSS 服务，接受浏览器 MCCP 呼叫消息。miniSIPServer 要求（1）证书和密钥保存在「应用数据目录」的「wrtcCert」子目录下；（2）文件必须是 PEM 格式；（3）证书保存为 server.crt 文件，密钥保存为server.key 文件。例如，在 Linux 系统中这两个文件应该如下所示：
$HOME/.minisipserver/wrtcCert/server.crt
$HOME/.minisipserver/wrtcCert/server.key
如果正常加载证书和密钥，miniSIPServer 将启动 WSS 服务并提示以下信息：
如果采用自签名证书，务必要注意在 Chrome、Firefox 等浏览器中允许加载自签名的证书。
在 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 的操作：
最新版本 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 就不太方便。越来越多的客户希望能在 SUSE、Fedora、openEuler 等操作系统上部署 miniSIPServer。
考虑到我们没有充足的资源（包括人力、设备等），我们决定发布 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 的「连选组」业务做了一些优化。
主要是对业务中的「话务员」特性进行修改和优化，请参考下图：
修改一：一位话务员可以同时配置在多个连选组中。以往限定了一位话务员只能配置在一个连续组中，这已经不符合现代企业的要求。企业中有些员工往往承担复合性工作，因此有很大可能需要同时支持多个连选组，新特性适配了这个需求。
在电路电话时代，话机终端缺乏足够的能力，因此通常「连选组」会允许话务员拨打特定的电话登录、或者登出连选组。出于以下几方面的考虑，miniSIPServer 新连选组业务不再支持话务员登录、登出操作：（1）如今的 SIP 终端多数都具备足够的能力，可以在终端侧实现「免打扰」等功能，因此没有必要再手工登录或者登出。（2）一位话务员同时支持多个连选组后，简单的登录、登出无法满足需要，需要修改为针对特定的连选组进行操作，拨号变得繁琐而没有必要。
修改二：如果连选组的组策略是「线性策略」，我们可以指定话务员的顺序号，从而设定话务员被选择的顺序。以往是按照话务员登录系统的先后顺序默认为组的选择顺序，其实就是随机顺序，这无法满足目前的需求，实际情况中有些话务员在组内的优先级别总是会有差异。话务员设定的「线性策略顺序号」越小，则越先被连选组选中。如果顺序号相同，则以登录系统的时间进行排序，先登录的优先被选择。
当然，这个新配置项对「轮选策略」无效，「轮选策略」总是尽量均匀地选择话务员，均匀分配工作量。
本地 miniSIPServer 和 云 miniSIPServer 的「连选组」业务都已经更新。业务的配置和使用都没有差异，请参考业务文档了解更详细的信息。