在Ubuntu 18.04上运行miniSIPServer
安装完Ubuntu后，从我们网站上下载miniSIPServer V32版本，直接点击安装，非常简单！稍微测试了一下，完美！
由于18.04版本是最新的长期支持版本，因此我们也强烈推荐客户使用这个版本来部署miniSIPServer。
再见，V24！
V24版本于两年前发布，是MSS第二个长期支持版本。现在，该说再见了！新的长期支持版本将是V32版本，我们将提供5年的支持服务。
V32版本基于目前的稳定版本V31。我们希望在正式发布前做尽可能多的测试，为此我们移除了V24版本的下载链接，仅保留V31版本的下载链接。根据我们的测试进展和客户的使用体验来判断，V31版本已经相当稳定。如果您是初安装MSS或者升级MSS，V31是一个非常好的选择。
V32目前开发、测试顺利，预计在2018年年初的时候发布。
V31最终版
我们发布了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”，这次库替换会比以前版本更稳定、更安全。
SIP协议栈更新
最近我们和几位客户配合处理一些与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自身永远不会发出这类号码格式。
对接中国电信IMS网络
最近帮助一位客户部署MSS服务器，对接中国电信IMS网络。在本次对接中，中国电信的软交换是ZTE的设备（至少SIP消息中的User-Agent是这么描述的），存在一些问题，需要特别注意配置方法才能完成对接。
由于中国电信是提供账号、密码信息进行对接，因此在MSS中应配置“外线”，其中需要注意的是以下几个关键点：
鉴权用户
通常外线配置中，默认采用“外线/账户”做鉴权用户（或者配置单独的鉴权ID）。而ZTE设备要求采用完整的URI作为鉴权用户名，因此在MSS的外线配置中，必须配置“鉴权用户名应包含地址信息”项，请参考下图。
设置该项后，例如上图的信息，MSS将采用“+8612345678@gd.ctcims.cn”作为鉴权用户名进行鉴权操作。
如果不采用完整格式的鉴权用户名，IMS网络会返回“403 Forbidden”拒绝注册和呼叫。我们认为这实际是ZTE软交换的缺陷，因为鉴权信息中本来就携带了域信息，无论鉴权用户名是否携带域信息，应该都不影响鉴权。如果您在与其他IMS设备对接时，也遇到了类似的问题，建议试试上述配置項。
Proxy设置
在中国电信的IMS网络中，对外的服务器地址作为逻辑域存在，实际上并不可访问。例如，上述例子中的“gd.ctcims.cn”就是域，而不是实际的SIP服务器。SIP消息实际应路由到指定的物理实体（在此我们理解为IMS网络前置的一个SBC或者Proxy），因此在MSS外线配置中，必须指明实际SIP消息需要路由的地址，请参考下图：
在Debian 9系统上运行miniSIPServer
很高兴看到最新的Debian 9版本正式发布了，我们在第一时间下载并进行了测试。
Debian 9是个很有趣的版本。考虑到TA是稳定版本，因此未来很多客户可能会选择在这个系统上运行miniSIPServer，确保系统运行正常就显得尤其重要。经过测试，我们吃惊地发现Debian 9相比以前的版本，变更了大量的库文件甚至是系统软件。默认情况下，如果不做任何修改，MSS无法正常运行在这个系统上。
这些天我们花费了大量的时间和资源来解决面临的一些冲突，将MSS的版本升级到最新的V31（build 20170621）。并且我们很高兴地宣布，MSS依然能支持以前的Debian系统，例如Debian 7和Debian 8。目前看一切都很完美！
如果您想尝试Debian 9系统，需要将MSS升级到最新的V31版本。请刷新文档进一步了解依赖库的细节，以便正确运行MSS。
Citel科技宣布与MyVoIPApp miniSIPServer完成互操作测试
纽约阿姆斯特（AMHERST, NY），中国深圳 – 2016年8月4日 – Citel科技非常高兴地宣布已成功完成与MyVoIPApp公司的miniSIPServer产品完成互操作测试。miniSIPServer是一款SIP-PBX软件，专为中小型企业打造，包含丰富的业务特性，也非常容易使用，能在多种平台运行，例如windows和linux，同时能适应IPv4和IPv6网络。
Citel科技的Portico™ TVA™产品支持将现有电话系统顺利迁移到VoIP系统，无需更改现有的布线结构，不需要订购新的IP电话，也不需要安装以太网供电的交换机。客户们可以保留现有的数字电话、模拟电话以及Centrex电话等，无需采用SIP电话。这是个快速、低成本的VoIP迁移解决方案。
Citel市场和销售总裁Ian Gomm如是说：“联合这两个创新产品，能提供最快、最节省成本的解决方案，极为方便企业将传统的电话网络升级为现代的统一通信系统”。
应一位知名度极高的客户的要求，Citel和MyVoIPApp开始进行互操作测试。这位客户正寻找基于windows平台的软交换系统构建跨国家通信网络。“多年以来我们承担过与众多IP PBX产品的互操作测试，同时也知道有时会有一些系统比另一些更容易使用、更有竞争力。 miniSIPServer对我们来说是全新的产品，但是我的确非常高兴地收到工程师的初步测试反馈：这个系统非常容易使用，而且互操作非常顺利”，Citel工程副总裁Andrew Davies说到。“后续测试展示了相当复杂的状态监视以及BLF（忙灯指示）功能，我看到miniSIPServer和Portico™ TVA™配合得完美无缺”，Andrew继续说道，“我们期待双方能进一步发展合作关系”。
关于Citel科技公司（citel.com）
Citel为中小企业、大型企业以及业务提供者提供低成本、高效率的IP电话系统解决方案，客户可以保留现有的PBX架构。单分支或者多分支商业机构现在能按自己的节奏部署下一代IP应用程序，对业务影响极小。业务提供者可以快速部署托管式IP电话业务，无需“拆除替换”现存的企业PBX终端和局域网布线。Citel位于纽约Amherst，同时在英格兰和多伦多也有分支机构。
关于MyVoIPApp（myvoipapp.com）
MyVoIPApp于2007年在中国深圳创立。虽然是个小公司，但是所有成员都具有至少十年的通信领域经验，公司聚焦于通信技术，在VoIP市场取得强劲的增长。
Invalid CSeq number
最近一位客户报告了一个问题：他的外线始终无法注册到VoIP运营商的网络。这让人倍感奇怪，毕竟“外线”是MSS非常基础的功能，已经和众多VoIP运营商对接过，我们从没想到过“外线注册”居然会有问题。
抓取了相应的log，发现该运营商返回了“400 Bad Request”消息，其中携带了以下原因信息：
P-Registrar-Error: Invalid CSeq number
我们检查了REGISTER消息，MSS在处理CSeq时并没有任何问题。以下是MSS消息的摘要：
==> REGISTER sip:sip.xxx.com SIP/2.0 ... Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001. CSeq: 13 REGISTER ... <== SIP/2.0 401 Unauthorized ... Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001. CSeq: 13 REGISTER ... ==> REGISTER sip:sip.xxx.com SIP/2.0 ... Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001. CSeq: 14 REGISTER ... <== SIP/2.0 400 Bad Request ... Call-ID: 18BF67854AE23D6D2CD772AFMSS002A0001. CSeq: 14 REGISTER P-Registrar-Error: Invalid CSeq number ...
我们再次检查了RFC3261规范中的定义：
A UA MUST increment the CSeq value by one for each REGISTER request with the same Call-ID.
显然我们是完全正确的，但是为什么对端会拒绝了注册呢？
最终我们尝试修改了Call-ID参数后注册成功。这让我们更感困惑！RFC3261规范很清楚地说明了注册流程中Call-ID参数的注意事项：
All registrations from a UAC SHOULD use the same Call-ID header field value for registrations sent to a particular registrar.
我们认为这个VoIP运营商的系统是不专业的。不幸的是，该运营商很难去升级他们的系统，因此我们在MSS中增加了一个开关变量来控制这种情况：
[sip] gVarSipRegSameDialog=0
如果您在与某些VoIP运营商系统对接时遇到类似的问题，请在“mss_var_param.ini” 文件中增加上述参数并重启MSS。
对抗SIP扫描
一位客户向我们报告：他的MSS服务器可能被黑客攻击。我们一起检查了MSS产生的呼叫详细话单，数据显示某人用另外一部SIP电话注册了同样一个分机号，并产生了大量的呼叫。
很显然，这是个非常严重的问题。我们推测这位“黑客”可能采用了发送大量SIP消息的方式来尝试上述分机的密码，并最终破解了密码。MSS以前的版本没有考虑这种异常情况，总是会允许SIP话机不停使用密码进行鉴权，直到最终通过鉴权为止，这就导致某些人刻意不停地扫描和尝试分机和密码。
为阻止这种情况，我们升级了MSS的版本，提供“失败则阻止（fail to ban， F2B）”特性。一旦SIP话机在一分钟内鉴权失败了若干次，则MSS会视之为“恶意扫描”并屏蔽其IP地址若干小时，期间MSS将拒绝所有来自该IP地址的SIP消息。这样迫使某些人几乎不可能破解SIP分机的密码。
F2B特性默认就开启，并且用户无需做任何配置。
V25版本更新，去掉webRTC特性
最近我们更新了V25版本，修正了一些bug、做了一些优化，系统更加稳定。最重要的是：从这个版本开始，我们删除了webRTC特性。
在以前的blog或者文档中，我们说明了MSS webRTC特性适用于Google Chrome浏览器。Chrome升级到V48版本后，对webRTC特性做了一些改动。一如以往，这些改动没有考虑到和以前版本的兼容，这迫使我们再次不得不向客户道歉并跟进修改。综合考虑后我们认为，可能webRTC特性更适合公众网络业务，例如Google自身的hangouts业务。缺乏灵活性、兼容性考虑，webRTC可能不适合中小型企业通信网络市场。
因此我们从V25版本开始砍掉了这个特性，不过仍然保留在V24（LTS版本）中。如果您仍然在使用webRTC特性，请注意保持Chrome浏览器的版本不要超过V47版本。
部分虚拟虚拟服务器变更
最近我们对某些虚拟服务器进行了变更，请注意以下几点：
STUN服务器
每个虚拟SIP服务器都同时启动了STUN服务，例如，如果您的虚拟服务器地址是“1234.s1.minisipserver.com”，那么STUN服务器地址也同样可以是“1234.s1.minisipserver.com”。
而现在我们单独部署了独立的简单STUN服务器“stun.minisipserver.com”。默认情况下，我们推荐用户采用这个STUN服务器，所有虚拟SIP服务器节点都可以采用这个新的STUN节点。当然，您仍然可以采用虚拟服务器地址做自己的STUN服务器地址。
SMTP服务器
在语音邮箱业务中，我们需要SMTP服务器发送带语音文件的电子邮件。以前每个虚拟SIP服务器都可以配置客户自己的SMTP信息。但是实际部署过程中我们发现一些问题，例如大部分用户都会采用gmail的SMTP服务。而Gmail默认是没有打开POP/SMTP服务的，客户需要在gmail配置中单独打开这些配置项。另外，gmail要求明确授权其他接入者使用用户的SMTP服务，大部分客户实际上并不清楚这些细节，因此大量的语音邮箱业务都以失败告终。
考虑各种状况，我们决定去掉SMTP的各项配置，即用户不再需要配置自己的SMTP信息，系统会采用我们自己的SMTP服务器发送语音邮件。当然这样也有一点不足之处：您可能需要检查“垃圾”邮箱文件夹，您的邮件系统有可能会将我们的邮件作垃圾邮件处理。