技术文档以及常见问题解答
部署VoIP网络时，我们常常会在miniSIPServer中配置外线连接VoIP运营商的服务器。考虑到市场中有大量的VoIP运营服务商，因此经常有客户咨询我们如果配置miniSIPServer来连接这些运营商的网络。
实际上在“小型企业建立IP-PBX系统指南”这篇指导文档中，我们已经提供了一个简单的外线配置，连接VoIP运营商“call centric”。您可以参考这篇文章了解VoIP网络和外线的相关细节。另一方面，我们在“常见问题”文档的“外线”章节，也给出了一些其他运营商的配置参考。如果您有兴趣或者需求的话，也可以参考这些文档，希望这些文档帮助您部署VoIP网络。
我们要求必须使用 email 邮箱地址来注册、激活云 miniSIPServer 帐号（minisipserver.com），因为我们需要通过email及时反馈系统状况给您，有时候我们也需要发送一些必要的通知给您，比如账户余额的情况，确保您的系统能保持正常、稳定地运行，避免意外情况对您的 VoIP 系统造成不必要的冲击。
出于保护客户隐私的考虑，我们的服务器全部部署在有最严格法律规范约束的美国、德国两地。我们也承诺绝对不会泄漏您的email邮箱地址，也绝对不会用于营销等目的，仅仅是作为系统维护时的联系手段而已。
目前我们已经与全世界绝大多数邮件服务商都工作良好，唯一让我们感到困惑的是大陆地区的QQ邮箱。我们已经多次收到用户的抱怨，注册云miniSIPServer账户后，无法收到激活邮件。我们检查了自身系统的相关情况，发现QQ邮箱退回了我们的邮件，原因是我们的IP地址发送了过多的邮件。
根据我们的日志，大陆地区用户用QQ邮箱注册的情况并不多，频率大约是一周二三个而已，我们的邮件系统不可能频繁发送激活邮件。我们完全有理由相信，QQ 邮箱简单粗暴地过滤了海外邮箱地址。我们尝试联系 QQ 邮箱的支持部门进行沟通，但是很遗憾，没有获得反馈，状况也没有改善。
因此，如果您是大陆地区用户，建议您不用QQ邮箱注册云miniSIPServer帐号。我们推荐采用163或者outlook邮箱，这些都没有任何问题。当然，如果您有海外邮箱帐号，比如gmail、yahoo等，那就更没有问题。
在某些VoIP网络部署中，我们需要采用“SIP中继”与其他VoIP服务器或者网关进行互联。在媒体处理方面，我们希望（1）本地分机之间的媒体流不经过MSS服务器，而（2）与其他VoIP服务器对接的呼叫中希望能通过MSS转发媒体流。
为解决这个需求，我们更新了V32版本，在“SIP中继”的“出呼叫”配置中，可以单独设置是否需要MSS来转发媒体。请参考下图：
请注意，目前仅支持转发语音流，不会转发视频流。
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
“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消息需要路由的地址，请参考下图：
通常我们不限制SIP中继的并发呼叫数，也就是说，默认情况下能呼叫多少就呼叫多少。如果对方资源有限，自然会拒绝多余的呼叫。然而在一些应用场景中，客户们希望MSS能主动对呼叫进行限制。
为此我们拓展了SIP中继中的配置，分别对“呼入呼叫”和“呼出呼叫”的最大并发呼叫数进行限制，超出最大呼叫数的呼叫将被禁止或者抛弃。请参考下图：
需要注意的是：
（1）这两项配置是独立的，因此可以对呼入和呼出做出不同的限制决定。
（2）如果将其中一项或者两项配置为0，则可以限制为只允许呼入，或者只允许呼出。
在最新发布的V30版本中，对“一号多机”业务做了点改动。原有版本中默认所有分机都具有该业务能力，也就是说，任何一个分机账号都允许多部设备或者话机同时注册和使用。在实际应用过程中，客户们反馈这样做虽然简化了配置，但是其实带来了管理问题，并不想所有分机都允许多机注册，只有部分或者特定的分机才可以这样做。
考虑到这种情况，我们在分机配置中增加了“一号多机”业务权限配置。只有明确配置了该权限位的分机，才允许多机注册和使用。请参考下面的图例。
本次修改同时适用于本地MSS版本以及云MSS版本。
我们可以使用“系统黑白名单”来过滤、阻止匿名呼叫。请点击菜单“业务 – 系统黑名单”，添加以下记录：
caller number prefix = anonymous called number prefix = * rate = 100
该记录的作用就是：100%阻断来自“anonymous”的呼叫。
有些匿名呼叫的主叫号码可能会有差别，不过仍然可以在“系统黑名单”配置类似的记录进行过滤。
最近一位客户报告了一个问题：他的外线始终无法注册到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。