基于windows以及Ubuntu的专业SIP服务器软件
如果您使用以前版本的 miniSIPServer，如果想让 miniSIPServer 转发媒体流，miniSIPServer 只会转发语音流而去掉视频流。
这主要是因为视频流会占用太多的带宽，同时也要求服务器有足够的计算能力。很多设备实际上达不到这样的要求。但是越来越多的客户要求我们改进这点，在转发语音流的同时也转发视频流，因为他们的设备目前已经足够强大，而且网络也有足够的带宽。
既然如此，这个要求似乎非常合理，因此我们认为应当升级 miniSIPServer 满足这些客户的需求。
因此最新版本（20210604 构建版本）正式发布，这个版本在转发媒体流的时候，将同时转发语音流和视频流。
升级版本后无需更改配置，您唯一要注意的是硬件的计算能力和网络的带宽是否满足需求。
某些时候我们希望知道系统当前的呼叫状态，例如有那些呼叫、谁正在呼叫等等。miniSIPServer 已有一个“实时话单”窗体，可以显示已经结束的呼叫的话单信息。这个“实时话单“窗体实际上是”半实时“，它无法显示目前还在进行中的呼叫的状态。
显然，我们需要更新这个窗体来显示更多的呼叫细节信息，下面是新版本的”实时话单“窗体：
这个新窗体将根据呼叫的当前状态，将呼叫标记成不同的颜色。例如，灰色的记录是已经释放的呼叫，黑色记录是刚刚发起的呼叫，蓝色记录是被叫开始振铃的呼叫，而红色记录则是被叫已经应答的呼叫。
根据这些信息，您现在就能非常直观地了解系统当前所有的呼叫细节，相当有趣吧!
当然，您需要指定 miniSIPServer 实时显示话单，并同时指定显示何种话单。请点击菜单“数据 / 系统信息 / 话单”，请参考以下配置：
其中，需要特别注意的是：“产生失败呼叫话单”和“实时显示话单信息”两项必须要勾选中。其他配置项请参考用户手册文档的说明。
一般情况下，我们在用户的配置文件中设置振铃组业务。一个用户只能设置一个振铃组，在多数情况下，这个设定都能工作得很好。
众所周知，现在是艰难时刻。部分公司不得不裁剪人力资源以减少运营费用，因此剩余的人员就可能需要承担更多的工作。比如同一个员工有可能同时分配到多个工作组（振铃组）。实际上已经有一些客户要求我们适配这个需求。
我们非常理解这个请求，因此升级了 miniSIPServer， 采用一个新的方式来支持振铃组业务。
简而言之就是新增了两张表。一张表用于定义振铃组及其分机用户，请参考下图：
另一张表配置了振铃组检测方式，miniSIPServer 根据呼叫中的被叫号码，判定是否需要触发振铃组。请参考下图：
业务文档已经更新，请点击此处了解更多细节。
在部署 VoIP 网络时， 有些场景会要求使用定制化的资源文件，例如 自己的语音文件、特殊的 IVR 流程、自己的鉴权文件等。 以前的 miniSIPServer 版本将这些文件保存在安装运行目录（或者子目录）下。
这有可能导致管理方面的问题。卸载、升级 miniSIPServer 时，我们不得不非常小心地备份这些定制的资源文件。
V38 (build 20210108) 版本试图解决这个困扰。 所有的定制化资源文件和默认的资源文件分离出来，单独保存在应用数据目录（AppData 目录）及其子目录下。
例如，定制的语音文件将保存在 custAnn 子目录中。一旦 miniSIPServer 被卸载或者升级，这些语音文件不会受任何影响。
请参考在线文档了解更多细节。
V38 之前版本的 miniSIPServer 将配置数据文件保存在当前安装目录下。在某些场景中， 这实际会遇到一些问题。 比如在 windows 系统中， 如果用户将 miniSIPServer 安装在系统盘（通常是 C 盘），有可能 windows 会禁止 miniSIPServer 写文件（除非用户明确以管理员权限运行 miniSIPServer）。
在 Linux 系统中， 也会有类似的权限问题。 miniSIPServer 默认安装在 “/opt/sipserver” 目录， 如果系统管理员（比如 root ）运行了 miniSIPServer 并创建、修改了本地数据存储文件， 其他用户再运行时就没有权限读、写这些文件，从而导致启动 miniSIPServer 失败。
因此 V38 版本做出了一点改变，将数据存储在当前用户自己的目录下。 在 Windows系统中，这个目录就是用户的应用数据（Application data）目录。而在 Linux 系统中， 这个目录就是用户的 HOME 目录。
请参考在线文档了解这个变动的细节信息。
另一方面， miniSIPServer 会在启动时明确提示当前数据的保存目录。
非常完美，直接安装运行即可！ 而且系统界面非常美观，值得尝试！
在部署 VoIP 网络时，经常会遇到“语音不通”或者“语音单通”等问题。这通常都是由于私有网络导致的，例如，部分 SIP 电话和 miniSIPServer 部署在路由器后面，而部分 SIP 设备（包括 SIP 电话）部署在另一个不同的网（可以是私网、也可以是公网）。
为解决这类语音问题，通常我们都建议在路由器中手工配置“端口转发”，将必要的一些端口转发到 miniSIPServer，由 miniSIPServer 来负责转发不同网之间的语音流。 如果您对路由器比较熟悉，配置“端口转发”相对就比较容易。
然而部分客户不熟悉路由器配置，或者在配置时可能会出些错误，因此我们在 miniSIPServer 中增加了个小特性来帮助完成“端口转发”的配置。
这就是UPnP（Universal Plug and Play， 通用即插即用）。 UPnP 能帮助 miniSIPServer 自动进行端口映射。
首先，您需要确认路由器支持UPnP，并且已经打开了这项功能。
接着，在 miniSIPServer 的主窗体，请点击菜单“数据 – 系统配置”，并选择配置项“采用 UPnP 请求路由器映射端口”即可，如下图所示：
默认情况下，miniSIPServer 会请求映射以下端口： SIP （基于UDP）端口、转发媒体流的端口。
另一方面，多数路由器（尤其是家用级别的路由器）会限制 UPnP 请求的端口数量，比如通常会少于30个，因此如果您的 miniSIPServer 是100客户及以上版本，您还是必须像以前一样手工配置“端口转发”。
Ubuntu 20.04 是最新的长期支持版本，因此 miniSIPServer 也必须支持这个新发布的版本。
不幸的是，Ubuntu 20.04 版本砍掉了对 Qt4 的支持，因此我们需要采用 Qt5 开发库更新 miniSIPServer。 miniSIPServer 升级到 V37 (build 20200424) 后，可以成功支持 Ubuntu 20.04系统版本，请参考下图。
另外，miniSIPServer 的 Windows 版本仍然选择停留在 Qt4 程序库，因为我们目前还需要支持部分客户的老旧系统版本，例如 XP、7等。在开发计划中， V38 版本将全部迁移到 Qt5 版本，同时将正式告别 XP 等老旧系统。
在部署 miniSIPServer 时，我们可以通过 IVR-XML 来订制自己需要的IVR业务流程，最常见的就是“自动话务员”业务。根据以往的 IVR-XML 功能集，我们可以使用“callto”动作发起新的呼叫，同时结束整个IVR流程。
但是，如果我们想监视呼叫过程中的某些事件，例如“被叫忙”，并根据这些事件改变IVR的流程，触发新的动作（action），我们该怎么做呢？
目前最新的 V37 版本已经发布，在这个版本中，扩展了一个与 IVR-XML 有关的关键特性。我们可以在“callto”动作中，配置“monitor-events”元素，对呼叫事件进行监视，并在事件发生时，将IVR流程转向新的动作。
例如，以下示例中，在“callto”动作中配置需要监视的事件：
<action method="callto" name="mainAction"> <destination>100<destination> <monitor-events> <monitor-event detection="busy" nextaction="callto101"/> </monitor-events> </action>
在这个示例中，如果“callto”发起的呼叫，遇到被叫忙，则 IVR 流程将执行下一个动作“callto101”， 即对另一个用户发起新的呼叫。
请参考IVR-XML 在线文档，了解更多关于“monitor-events”的细节。
上述zip文件是一个简单的IVR-XML脚本示例，用于测试新的“callto”动作。将其解压缩并保存在”xml”子目录下（您可以在miniSIPServer的安装目录下找到这个子目录），并在miniSIPServer中配置新的触发条件进行测试。
