miniSipServer云通信产品
由于最近暴露的CPU幽灵和熔断漏洞影响很严重，数据中心服务商告知我们将在以下时间点重启所有的物理节点：
2018-01-19 7:00:00 AM UTC
请务必在这个时间点做好准备，减少此次维护工作对您的VoIP网络造成的不利影响。
由于此次重启是来自底层物理服务器的需要，因此我们所有的虚拟服务器会受影响。当然，配置数据不受影响。在维护窗口期间，所有的虚拟服务器都需要重启，所有虚拟VoIP网络都不得不中断运行。我们预期2小时的时间窗来完成这项工作，但实际所需要的时间应该大大少于这个预设值。
这是底层CPU漏洞导致的严重问题，我们没有别的选择，只能采取紧急维护行动确保整个系统的安全，对此造成的不利影响我们感到非常遗憾。如果您在后续系统维护期间有任何疑问或者问题，请及时联系我们。
“Sonetel.com”是一家VoIP运营商，提供各国本地电话号码服务。我们可以在MSS中添加外线，连接Sonetel的服务器。根据Sonetel给出的配置参考，有以下几方面的内容需要注意：
本文给出一个简单的示例，指导如何配置MSS与Sonetel互联。我们假设用户的SIP帐号是“abc@gmail.com”。
在MSS中，请点击菜单“数据 – 外线”，增加一条新记录。
在“基本配置”页中，外线类型是“连接到对端VoIP服务器”，用户名是“abc”，而“服务器地址/域”必须是“gmail.com”。
另外请注意，密码項应该是在注册sonetel帐号时的密码，而不是email帐号自身的密码。
由于sonetel前置了Proxy（SBC）来处理SIP消息，因此我们在外线中还需要指定这个Proxy地址。在“出呼叫”页面中，指定对应的服务器地址，如下图所示。
Sonetel代理服务器地址为“sip.sonetel.com”，在注册时sonetel发送的email邮件有相应的说明。如果未来有变动，参考sonetel邮件说明即可。
最近帮助一位客户部署MSS服务器，对接中国电信IMS网络。在本次对接中，中国电信的软交换是ZTE的设备（至少SIP消息中的User-Agent是这么描述的），存在一些问题，需要特别注意配置方法才能完成对接。
由于中国电信是提供账号、密码信息进行对接，因此在MSS中应配置“外线”，其中需要注意的是以下几个关键点：
通常外线配置中，默认采用“外线/账户”做鉴权用户（或者配置单独的鉴权ID）。而ZTE设备要求采用完整的URI作为鉴权用户名，因此在MSS的外线配置中，必须配置“鉴权用户名应包含地址信息”项，请参考下图。
设置该项后，例如上图的信息，MSS将采用“+8612345678@gd.ctcims.cn”作为鉴权用户名进行鉴权操作。
如果不采用完整格式的鉴权用户名，IMS网络会返回“403 Forbidden”拒绝注册和呼叫。我们认为这实际是ZTE软交换的缺陷，因为鉴权信息中本来就携带了域信息，无论鉴权用户名是否携带域信息，应该都不影响鉴权。如果您在与其他IMS设备对接时，也遇到了类似的问题，建议试试上述配置項。
在中国电信的IMS网络中，对外的服务器地址作为逻辑域存在，实际上并不可访问。例如，上述例子中的“gd.ctcims.cn”就是域，而不是实际的SIP服务器。SIP消息实际应路由到指定的物理实体（在此我们理解为IMS网络前置的一个SBC或者Proxy），因此在MSS外线配置中，必须指明实际SIP消息需要路由的地址，请参考下图：
RFC3262定义了一种方法，用于SIP对话中传递可靠的临时响应消息。简单地说，就是定义了一个新的SIP消息“PRACK”用于响应“临时响应”消息（是不是很拗口？）。我们一直以来都觉得这不是个好想法，实际上多数传统的SIP设备都没有支持RFC3262定义的能力。
然后最近情况有些变化。在某些需要和传统PSTN网络互通的场景中，各设备必须具备RFC3262能力。尤其是在某些4G-IMS移动网络，例如中国市场的移动网络运营商，如果呼叫中没有指示支持RFC3262能力，网络会直接拒绝呼叫。
所以我们升级MSS到最新的V31版本，主要特性就是支持RFC3262能力。新版本的MSS会在呼出呼叫的消息中明确指示“100rel”，告诉对端设备或者SIP话机可以采用可靠的临时响应消息，这些设备自行决定是否要触发RFC3262的流程。在收到呼叫时，除非对端或者SIP话机明确要求RFC3262流程，否则默认情况下MSS不会主动发起RFC3262流程。这样可以确保同时兼容传统VoIP网络以及IMS网络。
本次升级对用户配置没有任何要求。如果您在部署MSS的过程中，遇到与PSTN网络或者移动IMS网络对接失败的情况时，可以考虑升级到最新的MSS试试。希望您能喜欢我们的软件！
通常我们不限制SIP中继的并发呼叫数，也就是说，默认情况下能呼叫多少就呼叫多少。如果对方资源有限，自然会拒绝多余的呼叫。然而在一些应用场景中，客户们希望MSS能主动对呼叫进行限制。
为此我们拓展了SIP中继中的配置，分别对“呼入呼叫”和“呼出呼叫”的最大并发呼叫数进行限制，超出最大呼叫数的呼叫将被禁止或者抛弃。请参考下图：
需要注意的是：
（1）这两项配置是独立的，因此可以对呼入和呼出做出不同的限制决定。
（2）如果将其中一项或者两项配置为0，则可以限制为只允许呼入，或者只允许呼出。
在最新发布的V30版本中，对“一号多机”业务做了点改动。原有版本中默认所有分机都具有该业务能力，也就是说，任何一个分机账号都允许多部设备或者话机同时注册和使用。在实际应用过程中，客户们反馈这样做虽然简化了配置，但是其实带来了管理问题，并不想所有分机都允许多机注册，只有部分或者特定的分机才可以这样做。
考虑到这种情况，我们在分机配置中增加了“一号多机”业务权限配置。只有明确配置了该权限位的分机，才允许多机注册和使用。请参考下面的图例。
本次修改同时适用于本地MSS版本以及云MSS版本。
在新版MSS中我们增加了两项与话务员相关的业务：话务员强插以及话务员逾越。请参考业务文档了解这两项业务的细节。
本地MSS软件版本以及云MSS服务都为这两个业务进行了升级。目前MSS软件最新版本为V29版本。
下一个版本，即V30版本，将主要集中在“媒体网关”特性的优化上。如果您有任何建议和需求，欢迎您联系我们，我们十分乐意与您进行讨论。
最近我们更新了V25版本，修正了一些bug、做了一些优化，系统更加稳定。最重要的是：从这个版本开始，我们删除了webRTC特性。
在以前的blog或者文档中，我们说明了MSS webRTC特性适用于Google Chrome浏览器。Chrome升级到V48版本后，对webRTC特性做了一些改动。一如以往，这些改动没有考虑到和以前版本的兼容，这迫使我们再次不得不向客户道歉并跟进修改。综合考虑后我们认为，可能webRTC特性更适合公众网络业务，例如Google自身的hangouts业务。缺乏灵活性、兼容性考虑，webRTC可能不适合中小型企业通信网络市场。
因此我们从V25版本开始砍掉了这个特性，不过仍然保留在V24（LTS版本）中。如果您仍然在使用webRTC特性，请注意保持Chrome浏览器的版本不要超过V47版本。
最近我们对某些虚拟服务器进行了变更，请注意以下几点：
每个虚拟SIP服务器都同时启动了STUN服务，例如，如果您的虚拟服务器地址是“1234.s1.minisipserver.com”，那么STUN服务器地址也同样可以是“1234.s1.minisipserver.com”。
而现在我们单独部署了独立的简单STUN服务器“stun.minisipserver.com”。默认情况下，我们推荐用户采用这个STUN服务器，所有虚拟SIP服务器节点都可以采用这个新的STUN节点。当然，您仍然可以采用虚拟服务器地址做自己的STUN服务器地址。
在语音邮箱业务中，我们需要SMTP服务器发送带语音文件的电子邮件。以前每个虚拟SIP服务器都可以配置客户自己的SMTP信息。但是实际部署过程中我们发现一些问题，例如大部分用户都会采用gmail的SMTP服务。而Gmail默认是没有打开POP/SMTP服务的，客户需要在gmail配置中单独打开这些配置项。另外，gmail要求明确授权其他接入者使用用户的SMTP服务，大部分客户实际上并不清楚这些细节，因此大量的语音邮箱业务都以失败告终。
考虑各种状况，我们决定去掉SMTP的各项配置，即用户不再需要配置自己的SMTP信息，系统会采用我们自己的SMTP服务器发送语音邮件。当然这样也有一点不足之处：您可能需要检查“垃圾”邮箱文件夹，您的邮件系统有可能会将我们的邮件作垃圾邮件处理。
在“语音邮箱”业务中，MSS需要采用SMTP库发送语音邮件。考虑到MSS本身支持嵌入Python脚本，因此很容易就直接调用python-smtplib库发送邮件。这正是我们在以前的版本中的实现方式，一直工作得很好，我们也很满意。
然而smtplib库（python2.7携带）有点过时了，无法满足一些现代SMTP服务器的要求。另外，该库也有一个明显的缺陷：它是同步方式。这意味着发送邮件的过程中，会阻塞业务线程，导致性能低下。这在普通PBX应用场景中不是问题，但是在我们的云端通信系统中就显得不太合适了。
事情已经发生改变，我们也希望MSS能更加完美，因此决定开发一个新的SMTP库来发送邮件。新的SMTP库采用异步方式，有更高的性能，符合现代SMTP的各项要求。并且，采用C/C++语言实现。
我们已经更新了V23版本和云通信系统，都采用了最新的SMTP库。希望您能喜欢最新的版本。
另外，自从V23版本发布数月以来，我们得到的反馈非常之好，因此我们想是时候发布新的长期支持版本（即V24版本）以及新的稳定版本（即V25版本）了。按照版本计划，如果没有意外的话，我们将在今年年底或者明年年初完成上述版本的升级，敬请期待！