通常我们不限制SIP中继的并发呼叫数，也就是说，默认情况下能呼叫多少就呼叫多少。如果对方资源有限，自然会拒绝多余的呼叫。然而在一些应用场景中，客户们希望MSS能主动对呼叫进行限制。
为此我们拓展了SIP中继中的配置，分别对“呼入呼叫”和“呼出呼叫”的最大并发呼叫数进行限制，超出最大呼叫数的呼叫将被禁止或者抛弃。请参考下图：
需要注意的是：
（1）这两项配置是独立的，因此可以对呼入和呼出做出不同的限制决定。
（2）如果将其中一项或者两项配置为0，则可以限制为只允许呼入，或者只允许呼出。
在最新发布的V30版本中，对“一号多机”业务做了点改动。原有版本中默认所有分机都具有该业务能力，也就是说，任何一个分机账号都允许多部设备或者话机同时注册和使用。在实际应用过程中，客户们反馈这样做虽然简化了配置，但是其实带来了管理问题，并不想所有分机都允许多机注册，只有部分或者特定的分机才可以这样做。
考虑到这种情况，我们在分机配置中增加了“一号多机”业务权限配置。只有明确配置了该权限位的分机，才允许多机注册和使用。请参考下面的图例。
本次修改同时适用于本地MSS版本以及云MSS版本。
昨天我们正式发布了V30版本。正如以前所说，本次版本的主要特性是“媒体网关”。
实际上以前的版本已经有媒体网关功能，只是这些功能与呼叫控制、业务控制融合在同一个核心中，本身并不独立。对于小型或者中型商业部署环境，这样做没有问题（实际上一直运行很好）。但是对大型商业部署而言，比如我们的云通信系统，媒体网关和呼叫控制合并在一起会影响整个系统的性能。
我们决定将“媒体网关”分离出来作为一个独立的应用。在云系统中，“媒体网关”甚至运行在独立的设备上。多台呼叫服务器可以共享、互联同一台媒体网关服务器。
由于本地MSS和云MSS是采用同一个核心模型，因此我们将这个特性也移植回V30版本。不同之处在于：本地MSS将“媒体网关”作为程序内部一个独立的任务（线程）运行。
本次特性修改对配置文件、管理界面没有任何修改。默认情况下，您甚至感觉不到这次的修改。我们相信新的核心更加稳定、更加灵活。希望您能享受、喜欢我们的产品！
在新版MSS中我们增加了两项与话务员相关的业务：话务员强插以及话务员逾越。请参考业务文档了解这两项业务的细节。
本地MSS软件版本以及云MSS服务都为这两个业务进行了升级。目前MSS软件最新版本为V29版本。
下一个版本，即V30版本，将主要集中在“媒体网关”特性的优化上。如果您有任何建议和需求，欢迎您联系我们，我们十分乐意与您进行讨论。
最近释出了最新的Ubuntu版本：16.10，一如既往，我们下载并安装miniSIPServer进行简单的测试。运行很完美，没有任何问题，请参考下图。
如果您是在商业环境中部署miniSIPServer，我们仍然建议您将Ubuntu保留在以前的LTS版本，即14.04以及16.04等版本。
如果您是在测试环境或者个人环境中部署miniSIPServer，那就请尽情地享受最新的系统带来的快乐吧。
V28版本正式发布！我们在这个版本花费了数月的时间。 本版本的关键特性是新的业务引擎，即“Lua业务引擎”。
如您所知，以前的MSS版本的业务引擎采用Python语言编写，工作得非常好，但是仍然有一些限制。现在新版本中业务引擎采用Lua语言重新编写，我们简单介绍作出这一决定的几个关键因素。
（1）Lua语言更简单。Python是全栈、通用型语言，而Lua是嵌入式语言。Lua比Python少很多特性，但是胜在更简单。我们尽管非常喜欢Python，但是分析后仍然发现Lua更适合用于MSS来实现业务引擎。我们不需要全功能，只需要能封装、提供MSS核心功能和能力即可。
（2）最重要的稳定性。Python业务引擎采用一个Python虚拟机支持所有的业务实例，一旦其中一个业务发生未知异常导致虚拟机崩溃，所有的业务都会收到影响。而在新的业务引擎中，每个业务都会采用一个单独的Lua虚拟机，如果一个业务发生未知异常，其他业务不会受到任何影响。这实在是太棒了！整个MSS系统的稳定性达到了更高水平！
（3）更快！更快！更快！仅仅是语言层面，Lua就比Python更快。由于GIL的存在，Python无法满足高性能的要求，因此只能被局限在业务引擎层面。而Lua没有这个限制，每个Lua虚拟机都很微小而且独立，我们现在只是用Lua替换了业务引擎，后续我们甚至可以考虑实现基本呼叫引擎，未来已来！
在V28版本中，所有的Python业务已经被替换为Lua业务。您可以在“lua/services”子目录中找到这些Lua业务文件。如果您曾经自行修改过Python文件，升级到新版本后您需要自行修改对应的Lua文件。
由于Lua业务引擎只是后端技术的升级，因此默认情况下您不需要更改任何配置。
我们可以使用“系统黑白名单”来过滤、阻止匿名呼叫。请点击菜单“业务 – 系统黑名单”，添加以下记录：
caller number prefix = anonymous called number prefix = * rate = 100
该记录的作用就是：100%阻断来自“anonymous”的呼叫。
有些匿名呼叫的主叫号码可能会有差别，不过仍然可以在“系统黑名单”配置类似的记录进行过滤。
纽约阿姆斯特（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市场取得强劲的增长。
最近一位客户报告了一个问题：他的外线始终无法注册到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。
在外线的“出呼叫”配置中，我们增加了一个配置项“无应答时长”。该参数用于限制外线外呼时的无应答时间。请参考下图：
该参数默认值为0，也就是缺省采用系统定义的无应答定时器时长。如果设置了其他值，则优先采用该值。
例如，设置为15，则该外线的外呼呼叫如果在15秒内没有应答，外线将强制释放呼叫。