最近 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”、即不要求可靠性保证即可，那样 miniSIPServer 就不会发出 PRACK 消息。但是不幸的是，这家运营商的团队居然不知道该怎么做。
我们的客户就被耽搁在这了，他的业务被迫停滞下来。另一方面，我个人猜测这家（以及某些）运营商采用了开源的服务器，例如 Asterisk、FreeSwitch 等，来构建自己的解决方案，但是他们也许没有足够的专家来理解自己究竟构建了什么。
因此我们更新了 miniSIPServer，在外线的配置中增加一个选项用于关闭“100rel”能力，如下图所示：
一旦勾选了这项， miniSIPServer 向外线发出 INVITE 消息时，将不会再携带“100rel”参数。如果您对接了类似荒谬的运营商，请试试这个选项。
最近有很多客户向我们反映，他们收不到注册账号时系统发送的激活邮件。大部分客户使用的电子邮件都是来自某些免费的邮件系统，例如 gmail、163等。
起初我们认为这些系统将我们的激活邮件转移到“垃圾”分类中去了，但是客户们在那也没有找到相应的邮件，因此我们判断这些电子邮件系统拒绝了来自我们的邮件。
我们完全可以理解这些系统的处理方式。 我们的系统会发出大量的邮件，包括激活邮件、账户余额提示邮件等等，这些系统可能据此将我们判定为垃圾邮件发送者。
这让我们很困扰，而且我们实在不愿意这样，因此我们决定不再接受用免费邮件地址来注册 miniSIPServer 云系统的账号。我们希望我们的系统被视为严肃的云通信系统，当然我们也衷心希望客户们能理解这点。
在 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 数据包，然后尽力平滑语音的混音过程。另外，我们不得不指出，这显然增加了服务器的 工作负荷。
最近我们更新了 miniSIPServer 以适应 4K 分辨率显示屏的显示效果，但是我们发现，如果想获得非常完美的效果，必须同时升级我们现有的开发工具链。
然而新的工具链不再支持 Windows XP/2003 操作系统。这些操作系统非常棒，勤恳、可靠、任劳任怨，我们一直非常喜爱、信任这些老旧的系统。现在是时候道别了，我们将继续前行。
如果您是在 Windows 系统上部署 miniSIPServer，最新版本（V40）及后续版本将不再支持 Windows XP/2003 系统，最低要求为 Windows 7 （或以上）版本。我们也同步重新构建了 Debian / Ubuntu 系统上的版本，以适应高分辨率的显示需求。
请享受新版本吧。如果有任何问题、或者建议，欢迎您和我们联系。谢谢！
最近有客户向我们报告了一个问题：miniSIPPhone 在 4K 屏幕中界面异常。如下图所示：
在构建图形界面（包括 miniSIPPhone 以及 miniSIPServer）时，我们采用绝对位置、长度来安排界面中的各个组件，因此如果屏幕具备很高的分辨率时（例如 4K 屏幕），绝对坐标值就显得非常小、甚至过于紧凑。
为了解决这个问题，我们将图形界面中的布局、组件全部换成相对坐标、相对尺寸。当然，同时修改、升级了 miniSIPPhone（V8.4） 以及 miniSIPServer（V39 build 20220823）。
另一方面，我们同时也修改了 miniSIPServer 对话框的尺寸、风格、以及布局，因此 miniSIPServer 的图形界面整体上更统一、更整齐，使用感受也会更舒服一些。
众所周知，miniSIPServer 可以运行在 Linux 系统，因此常有客户咨询我们是否有 Linux 平台的 SIP 终端软件，大家的初衷是将整个 VoIP 系统构建在 Linux 环境中。实际上 Linux 环境有非常多的选择，例如 linphone、jami 等。
最近发布了一个新的 SIP 软终端，而且非常重要的是，它是 Gnome 项目的核心应用，这就是“Gnome Calls”。在 Debian 的软件库中，这个软件被描述为“Make and receive PSTN phone calls”，而最新版本的 Calls 可以支持 SIP 协议，在 Gnome 项目中的描述已经修改为“Make phone and SIP calls”。
在 Debian 系统中非常容易安装 Calls，请使用以下命令：
sudo apt install gnome-calls
以下截图是 Calls 运行时的主窗体界面：
点击菜单“VoIP Accounts”即可添加 SIP 账号。大多数项与其他 SIP 终端软件的配置基本一致。例如，在我们的测试环境中， miniSIPServer 的地址是“192.168.3.42”，给终端分配的账号是“100”，请参考以下配置：
请注意：（1）默认的端口是0，建议修改为5060；（2）添加完账号，需要使能后才能向服务器（也就是 miniSIPServer）发起注册、并正常使用。Calls 没有显示账号的运行状态，因此我们需要检查 miniSIPServer 的分机窗体来检视分机的实时状态。
拨打呼叫时，在“Dial Pad”面板直接输入被叫号码（例如101）即可，如下图所示：
如果有入呼叫，在弹出的窗体中接听、或者拒绝呼叫：
从各方面使用情况判断，“Gnome Calls”目前还比较简单、粗糙，显然后续还需要加入很多的特性和功能。如果我们希望在 Linux 环境中部署 VoIP 网络、同时希望各网元都是纯粹的 Linux 应用，“Gnome Calls”是个不错的选择。
希望各位也会喜欢这些软件。