会议室以及其他
近日 miniSIPServer 升级到V60版本，这是最新的、可用于商业部署的稳定版本。第一个重大特性就是“会议室”业务，该业务支持不超过 5 个本地分机用户的会议呼叫。请参考业务文档了解细节。miniSIPServer 云也同步升级支持该业务。
另外，正如我们在前一篇博客中提到，V60 业务最终移除了部分老旧的业务，例如呼叫卡、话吧。这些业务曾经对我们某些特定的客户非常重要，但就目前而言该对这些业务说再见了。
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 的附加参数
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 附加参数”项，请参考下图：
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
最近我们更新了 miniSIPServer 以适应 4K 分辨率显示屏的显示效果，但是我们发现，如果想获得非常完美的效果，必须同时升级我们现有的开发工具链。
然而新的工具链不再支持 Windows XP/2003 操作系统。这些操作系统非常棒，勤恳、可靠、任劳任怨，我们一直非常喜爱、信任这些老旧的系统。现在是时候道别了，我们将继续前行。
如果您是在 Windows 系统上部署 miniSIPServer，最新版本（V40）及后续版本将不再支持 Windows XP/2003 系统，最低要求为 Windows 7 （或以上）版本。我们也同步重新构建了 Debian / Ubuntu 系统上的版本，以适应高分辨率的显示需求。
请享受新版本吧。如果有任何问题、或者建议，欢迎您和我们联系。谢谢！
适配 4K 屏幕
最近有客户向我们报告了一个问题：miniSIPPhone 在 4K 屏幕中界面异常。如下图所示：
在构建图形界面（包括 miniSIPPhone 以及 miniSIPServer）时，我们采用绝对位置、长度来安排界面中的各个组件，因此如果屏幕具备很高的分辨率时（例如 4K 屏幕），绝对坐标值就显得非常小、甚至过于紧凑。
为了解决这个问题，我们将图形界面中的布局、组件全部换成相对坐标、相对尺寸。当然，同时修改、升级了 miniSIPPhone（V8.4） 以及 miniSIPServer（V39 build 20220823）。
另一方面，我们同时也修改了 miniSIPServer 对话框的尺寸、风格、以及布局，因此 miniSIPServer 的图形界面整体上更统一、更整齐，使用感受也会更舒服一些。
call tag 以及 cause
有时候客户希望知道一些历史呼叫的细节，例如哪一方释放的呼叫、为什么会释放呼叫等。由于这些细节都不是实时呼叫的细节，我们无法用 miniSIPServer 内部的跟踪工具进行跟踪，因此我们更新了 CDR 功能，以便回溯信息、了解呼叫的更深一点的细节。
在 CDR 的 FCI（Furnish Call/Charge Information, “提供呼叫/计费信息”）字段中，我们增加了参数“callTag=”以及”cause=”。请参考下图 CDR 记录的细节：
“callTag=” 参数用于保存当前呼叫的在 miniSIPServer 内部的释放位置，根据这个参数，我们可以知道呼叫在哪里被释放了、以及谁释放了这个呼叫。例如，呼叫有可能是收到了主叫侧的 BYE 消息从而导致释放的，诸如此类。这个参数的具体数值是 miniSIPServer 系统内部值，目前不会向客户们公开具体值的含义。
“cause=” 参数用于保存呼叫释放时的原因值。如果 miniSIPServer 收到了被叫侧的 4xx 或者 5xx 消息、同时该消息中包含 Reason 头域、并且在该域中携带了 cause 参数，则 miniSIPServer 会使用该原因值释放呼叫。其他情况下， miniSIPServer 根据内部的呼叫情况使用自己的 cause 值释放呼叫。当然，无论哪种情况， cause 值都会保存在 CDR 记录的 FCI 字段中。
“回呼”业务更新
miniSIPServer 默认打开 UDP 端口 5080 接受来自应用服务器的 call-back 请求并发起两路呼叫，如果 miniSIPServer 是部署在公网，有可能收到外部很多不相关的 UDP 数据包。我们可以通过配置“应用服务器地址”进行 IP 地址鉴权，但是不幸的是，这个地址默认是空，miniSIPServer会接受外部数据包并进行后续操作， 这带来隐性危险。
因此我们更新了“回呼”业务，进行适度的保护，同时也稍微修改了业务的处理逻辑。请先参考以下新的配置界面：
（1） “应用服务器地址”的默认值修改为本地循环地址“127.0.0.1”，这样外部的数据包将无法通过地址鉴权而被直接抛弃。当然，我们还是可以将它配置为空，允许所有的地址向 miniSIPServer 发送 call-back 请求，但我们强烈建议不要这么配置。
（2） “本地监听端口”可以配置为0，一旦配置为0， miniSIPServer 将关闭“回呼”业务，因此就绝对不会接受外部的任何数据包。如果您的环境没有部署“回呼”业务，我们强烈建议将这一项配置为0。
（3）取消“外线模式”。部分客户经常问道这个配置项是什么意思，也经常被它搞糊涂。其实当初设置这个配置项，主要是让 miniSIPServer 自动在外呼号码前添加“出群呼叫前缀”（默认也就是“9”）。实际上，这个项确实特别不灵活，比如客户可能在“回呼”业务中可能同时呼叫本地分机和外部用户，这个配置就容易导致号码错误。因此我们取消了这一项的配置，如果希望呼叫外部用户，可以在 REQUEST 消息中明确添加出群呼叫前缀。也就是说， 应用服务器自己决定号码格式、自己需要清楚号码分析结果（也就是路由结果）。
请参考“回呼”业务文档了解更多的细节。
优化的振铃组业务
一般情况下，我们在用户的配置文件中设置振铃组业务。一个用户只能设置一个振铃组，在多数情况下，这个设定都能工作得很好。
众所周知，现在是艰难时刻。部分公司不得不裁剪人力资源以减少运营费用，因此剩余的人员就可能需要承担更多的工作。比如同一个员工有可能同时分配到多个工作组（振铃组）。实际上已经有一些客户要求我们适配这个需求。
我们非常理解这个请求，因此升级了 miniSIPServer， 采用一个新的方式来支持振铃组业务。
简而言之就是新增了两张表。一张表用于定义振铃组及其分机用户，请参考下图：
另一张表配置了振铃组检测方式，miniSIPServer 根据呼叫中的被叫号码，判定是否需要触发振铃组。请参考下图：
业务文档已经更新，请点击此处了解更多细节。