我们最近采用 bootstrap 4 重新构建了公司网站，请访问：
新界面最重要的特点就是适配了各种访问设备，现在您可以通过PC、手机、平板电脑等访问，各页面会自动调整格式以方便阅读（感谢 bootstrap 4!）。希望您能喜欢我们的新界面！
另一个重要的修改就是“去掉了论坛”。我们对论坛里层出不穷的垃圾广告给搞烦了，大量工作资源耗费在毫无意义的工作上，因此我们决定关闭论坛。如果您有任何问题或者建议，请直接和我们联系即可：
https://www.myvoipapp.com/cn/contact.html
miniSIPServer 支持客户录制根据需要录制自己的语音，并替换系统默认的语音文件。以前的版本中，如果客户需要升级 MSS 的话，每次都需要备份好自己的语音，并重新替换系统默认的语音。
这当然是个小小的麻烦。现在，最新的V32可以解决这个麻烦了。
MSS 启动时，将在“mss_ann”目录下自动创建子目录“cust_ann”，现在您所有的自定义语音文件都可以放在这个子目录下。当 MSS 卸载或者升级时，这个子目录和内部的所有语音文件都不会删除或者被替换。MSS 启动后，会自动读取并加载“cust_ann”子目录下的语音文件。
在 windows 系统，这个子目录默认应该是“d:/myvoipapp/minisipserver/mss_ann/cust_ann”。在Linux系统中，这个子目录默认是“/opt/sipserver/mss_ann/cust_ann/”。
请参考在线文档了解录制自定义语音的更多细节。
https://www.myvoipapp.com/cn/docs/others/how_to_record_your_own_audio/index.html
由于最近暴露的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邮件说明即可。
我们已经完成了V32版本绝大部分场景的测试，今天很高兴发布V32稳定版本。
正如您所见，目前V32是处于稳定版本分支。我们完成所有测试用例，并收到足够的客户反馈信息后，V32版本将升级到长期支持版本分支（LTS），预计将在明年年初发布正式版本。
请从我们的网站下载试用。
https://www.myvoipapp.com/cn/download/
希望朋友们能喜欢这个新的版本！
V24版本于两年前发布，是MSS第二个长期支持版本。现在，该说再见了！新的长期支持版本将是V32版本，我们将提供5年的支持服务。
V32版本基于目前的稳定版本V31。我们希望在正式发布前做尽可能多的测试，为此我们移除了V24版本的下载链接，仅保留V31版本的下载链接。根据我们的测试进展和客户的使用体验来判断，V31版本已经相当稳定。如果您是初安装MSS或者升级MSS，V31是一个非常好的选择。
V32目前开发、测试顺利，预计在2018年年初的时候发布。
我们发布了V31最终版本，也就是说我们未来的工作将集中于V32版本，这将是我们下一个LTS版本，取代发布已久的V24版本。
实际上，V31版本包含了很多重要特性。由于V31版本是V32版本的基线版本，因此我们仍然会在这个版本上持续更新和维护数月时间。请参考下面的章节了解几个关键更新的细节。
主要指Windows平台的工具链更新。
V31版本升级了几个重要工具。首先是VC++升级到VC2010，因此MSS将采用VC2010的运行库。VC2010比之前的VC2008要强大一些，另外在处理manifest问题时要好得多。
基础的SSL库从OpenSSL迁移到LibreSSL库。当然，在Linux平台，MSS目前仍然使用OpenSSL库，未来可能会统一到LibreSSL库。LibreSSL提供了官方的windows库，我们认为LibreSSL优化得比OpenSSL要好很多。如果部署了“SIP over TLS”，这次库替换会比以前版本更稳定、更安全。
最近我们和几位客户配合处理一些与IMS网络互联互通的问题。我们遇到了几个奇怪、老旧的SIP呼叫流程，并通过优化V31来适配这些需求。
首先是支持“18x 带/不带 SDP”流程。“18X”可以是180，也可以是183，因此您可以看到流程存在多种可能性，例如“180带SDP”、“180不带SDP”、“183带SDP”以及“183不带SDP”等。同时这些消息的顺序也是有差异的， 有些场景中我们先收到180，另一些场景中又先收到183消息。在多数场景中，这些消息实际用于播放不同的回铃音，因此对这些流程的支持，不仅仅涉及修改SIP模块，MSS内部的媒体连接处理实际上也相应作出了优化。
另一个关键点是对SIP-UPDATE消息的支持。某些IMS网络不通过18x消息来携带回铃音信息，它们转而使用SIP-UPDATE消息。我们也发现某些设备采用“SIP-UPDATE不带SDP信息”来保持对话的激活状态。这些处理非常有趣，我们希望在另一篇blog中比较深入仔细地讨论与此有关的流程。不管怎样，V31版本专门为此进行更新，支持了部分SIP-UPDATE功能流程。我们并没有完整支持这个消息的所有功能，同时MSS本身也不会主动发起SIP-UPDATE流程。如果MSS希望更改媒体，目前仍然是采用reINVITE消息及其处理过程。
在V31版本中，MSS也支持“tel”号码格式。在传统的软交换网络，软交换设备和PSTN网络互通时，有可能将这样的号码格式传递给MSS，我们不是很理解为什么这些软交换设备不将其转换成VoIP域的SIP-URL格式。现在V31支持对方发送这类号码格式，同样，MSS自身永远不会发出这类号码格式。
最近帮助一位客户部署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消息需要路由的地址，请参考下图：
很高兴看到最新的Debian 9版本正式发布了，我们在第一时间下载并进行了测试。
Debian 9是个很有趣的版本。考虑到TA是稳定版本，因此未来很多客户可能会选择在这个系统上运行miniSIPServer，确保系统运行正常就显得尤其重要。经过测试，我们吃惊地发现Debian 9相比以前的版本，变更了大量的库文件甚至是系统软件。默认情况下，如果不做任何修改，MSS无法正常运行在这个系统上。
这些天我们花费了大量的时间和资源来解决面临的一些冲突，将MSS的版本升级到最新的V31（build 20170621）。并且我们很高兴地宣布，MSS依然能支持以前的Debian系统，例如Debian 7和Debian 8。目前看一切都很完美！
如果您想尝试Debian 9系统，需要将MSS升级到最新的V31版本。请刷新文档进一步了解依赖库的细节，以便正确运行MSS。
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试试。希望您能喜欢我们的软件！