miniSIPServer 新 web 界面
我们最近更新了 miniSIPServer 产品的 web 管理界面，包括本地 miniSIPServer 产品以及云端 miniSIPServer。新界面更接近本地 miniSIPServer 的图形管理界面，请参考下图：
我们希望新界面能帮助已经熟悉本地图形界面的 miniSIPServer 用户，这些用户在面对“熟悉”的界面时能快速体验云端 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 附加参数”项，请参考下图：
临时响应的可靠性
众所周知，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 云系统的账号。我们希望我们的系统被视为严肃的云通信系统，当然我们也衷心希望客户们能理解这点。
优化：将IVR-XML文件装入内存
在多数语音交互的场景中， IVR-XML 文件都比较小，通常是几KB，因此收到呼叫触发 IVR 业务时，服务器都会从硬盘读取 IVR-XML 文件并触发相应的 IVR 流程。但是，如果负荷非常大，例如有大量的并发呼叫同时触发大量的 IVR 流程，miniSIPServer 将频繁读取硬盘上的 XML 文件。显然，这实际会影响服务器的性能。
因此我们做了点优化，将所有的 IVR-XML 文件都装入内存。如果这些文件没有被修改，IVR 业务就直接从内存中读取 XML 文件的内容。如果文件被修改了，miniSIPServer 会自动将修改后的 XML 文件再次装入内存。
这就意味着所有的 IVR 操作都是访问内存，不更改文件的情况下，不会再访问硬盘，miniSIPServer 运行比以前要快一些，在负荷沉重的时候尤其如此。
转发视频流
如果您使用以前版本的 miniSIPServer，如果想让 miniSIPServer 转发媒体流，miniSIPServer 只会转发语音流而去掉视频流。
这主要是因为视频流会占用太多的带宽，同时也要求服务器有足够的计算能力。很多设备实际上达不到这样的要求。但是越来越多的客户要求我们改进这点，在转发语音流的同时也转发视频流，因为他们的设备目前已经足够强大，而且网络也有足够的带宽。
既然如此，这个要求似乎非常合理，因此我们认为应当升级 miniSIPServer 满足这些客户的需求。
因此最新版本（20210604 构建版本）正式发布，这个版本在转发媒体流的时候，将同时转发语音流和视频流。
升级版本后无需更改配置，您唯一要注意的是硬件的计算能力和网络的带宽是否满足需求。
例行维护
数据中心通知我们将进行例行维护，会影响到我们虚拟服务器所在的部分物理主机服务器。这些主机将会安装一些紧急补丁并重启。
计划的维护时间（UTC时间格式）如下：
2020-08-07 03:00:00 上午 UTC
请注意以下几点重要信息：
(1) 维护窗口预期大约是2个小时，然而实际下线时间可能是45 ~ 60 分钟。
(2) 您的虚拟服务器将关闭，维护期间将无法访问。
(3) 虚拟服务器重新工作后，您可能需要重启 SIP 电话或者本地的 SIP 设备（例如网关)。
如果您有任何问题或者关注，请通知我们。感谢您的耐心和配合！谢谢！
在“语音邮箱”业务中使用个性化语音
由于云端miniSIPServer和本地miniSIPServer是基于同样的核心构建，因此 一般情况下大部分业务特性是相同的。有一些业务，由于某些条件的限制，有部分特性会有一些差异，比如“语音邮箱”业务。
本地miniSIPServer系统中，分机用户可以设置不同的留言语音提示，而在云端miniSIPServer系统中，每个虚拟系统有统一的留言提示音，分机只能使用系统统一的提示音。用户仅能替换这个统一的留言提示音，不能为每个分机单独设置不同的提示音。
最近我们升级了云端miniSIPServer系统。在云系统中，每个分机现在也能配置和使用不同的留言提示音。请参考下图，在分机的配置中，新增了“个性化语音ID”项，每个分机可以配置不同的语音ID，也就是可以使用不同的留言提示音。
当然，目前云系统用户仍然无法自行将语音上传到虚拟服务器。如果您要上传语音，请将语音文件发送给我们的技术支持团队，我们将手工将您的语音文件上传到虚拟服务器中。
语音文件上传后，您可以在管理界面中自行进行管理。请参考下图所示：
另一方面，您需要按照一定的规则要求创建语音文件，包括文件的格式、语音编码要求，等等。请参考在线文档了解更多细节。
清除“僵尸”虚拟服务器
在下个月末（2020-01-31），我们将采取行动，清除云通信系统中的“僵尸”虚拟节点。
我们将以下特征的虚拟服务器定义为“僵尸”节点，将在本次行动中被清除。
（1）该虚拟服务器对应的帐号长期没有登录操作。“长期”是指两年以来，即从2017-01-01以来。您可以在最近登陆一次您的帐号，从而避免虚拟服务器被本次行动清除。
（2） 自 2017-01-01 时间点以来，该虚拟服务器没有SIP终端注册，或者没有任何SIP呼叫。
由于“僵尸”虚拟服务器只会无谓占用我们的系统资源，对其他客户也不公平，因此请务必重视本次清理行动，感谢您的理解和支持！
2020-02-13 更新： 本次清理任务已经完成。未来我们将持续清理“僵尸”虚拟服务器，并且不会再进行通知。如果您最近的一年内没有登录过您的服务器节点 ，或者没有任何SIP呼叫，将被视为“僵尸”虚拟服务器被清理掉，请务必重视这点。
在IVR-XML流程中监视各种呼叫事件
在部署 miniSIPServer 时，我们可以通过 IVR-XML 来订制自己需要的IVR业务流程，最常见的就是“自动话务员”业务。根据以往的 IVR-XML 功能集，我们可以使用“callto”动作发起新的呼叫，同时结束整个IVR流程。
但是，如果我们想监视呼叫过程中的某些事件，例如“被叫忙”，并根据这些事件改变IVR的流程，触发新的动作（action），我们该怎么做呢？
目前最新的 V37 版本已经发布，在这个版本中，扩展了一个与 IVR-XML 有关的关键特性。我们可以在“callto”动作中，配置“monitor-events”元素，对呼叫事件进行监视，并在事件发生时，将IVR流程转向新的动作。
例如，以下示例中，在“callto”动作中配置需要监视的事件：
<action method="callto" name="mainAction"> <destination>100<destination> <monitor-events> <monitor-event detection="busy" nextaction="callto101"/> </monitor-events> </action>
在这个示例中，如果“callto”发起的呼叫，遇到被叫忙，则 IVR 流程将执行下一个动作“callto101”， 即对另一个用户发起新的呼叫。
请参考IVR-XML 在线文档，了解更多关于“monitor-events”的细节。
上述zip文件是一个简单的IVR-XML脚本示例，用于测试新的“callto”动作。将其解压缩并保存在”xml”子目录下（您可以在miniSIPServer的安装目录下找到这个子目录），并在miniSIPServer中配置新的触发条件进行测试。
