MYVOIPAPP.com全站启用加密

MYVOIPAPP.com全站启用加密

在过去的一周,我们一直忙于将MYVOIPAPP.COM迁移到新的云计算系统中。与此同时,我们将网站默认配置修改为HTTPs,即加密HTTP方式。

现在您访问我们的网站,如果是HTTP非加密方式,系统会自动切换到HTTPs加密方式。这有助于确保您和我们网站之间的连接是安全的,不会被网络上的未知人士或者机构观察甚至修改,确保您得到干净的、未被污染的信息。

既然我们的网站目前建立在新的云计算系统之上,理论上应该更稳定、访问速度更快。当然,凡事总有意外,如果您在访问过程中发现任何问题,请及时通知我们。我们将非常感激,谢谢!

在Ubuntu16.04系统上运行miniSIPServer

在Ubuntu16.04系统上运行miniSIPServer

昨天发布了最新的Ubuntu16.04版本,这同时也是最新的LTS(长期支持)版本,因此我们尽快地下载了该版本并作了相当程度的测试。

有很多库升级或者改变了,我们需要更新miniSIPServer来适应这些变化。如果您希望在16.04系统上运行miniSIPServer,或者您希望将已有的Ubuntu系统升级到16.04版本,您需要更新到新的miniSIPServer版本(build 20160422)。

其他没有什么区别。请参考下图中我们运行miniSIPServer的情况:

在Ubuntu 16.04运行miniSIPServer
在Ubuntu 16.04运行miniSIPServer
对抗SIP扫描

对抗SIP扫描

一位客户向我们报告:他的MSS服务器可能被黑客攻击。我们一起检查了MSS产生的呼叫详细话单,数据显示某人用另外一部SIP电话注册了同样一个分机号,并产生了大量的呼叫。

很显然,这是个非常严重的问题。我们推测这位“黑客”可能采用了发送大量SIP消息的方式来尝试上述分机的密码,并最终破解了密码。MSS以前的版本没有考虑这种异常情况,总是会允许SIP话机不停使用密码进行鉴权,直到最终通过鉴权为止,这就导致某些人刻意不停地扫描和尝试分机和密码。

为阻止这种情况,我们升级了MSS的版本,提供“失败则阻止(fail to ban, F2B)”特性。一旦SIP话机在一分钟内鉴权失败了若干次,则MSS会视之为“恶意扫描”并屏蔽其IP地址若干小时,期间MSS将拒绝所有来自该IP地址的SIP消息。这样迫使某些人几乎不可能破解SIP分机的密码。

F2B特性默认就开启,并且用户无需做任何配置。

V25版本更新,去掉webRTC特性

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服务器发送语音邮件。当然这样也有一点不足之处:您可能需要检查“垃圾”邮箱文件夹,您的邮件系统有可能会将我们的邮件作垃圾邮件处理。

IP地址鉴权

IP地址鉴权

本特性已经合入最新的V25版本(build 20160126)。

某些特殊的SIP设备,例如自动控制系统中的嵌入式SIP设备,往往不具备全SIP能力集,只能发起或者接受简单的SIP呼叫,不能进行账号和密码鉴权。部分设备甚至不支持发送“注册”消息到MSS更新自己的状态。

嗯,我们在MSS中可以将这些设备配置为“SIP中继”,但是这样也会丢掉一些关键特性,例如“振铃组”。在某些场景中,客户们希望能让所有设备同时振铃,这样我们就只能将设备配置为“分机”用户。

为满足这些需求,我们在“分机”中增加了“IP地址鉴权”的特性。也就是说,MSS可以不要求SIP终端首先进行注册,呼叫过程中也可以不再对账号和密码进行鉴权,只要SIP消息来自特定的或者预先配置的IP地址即可。请参考下图了解更多的细节:

IP地址鉴权
IP地址鉴权

另外,在新版本中我们同样也更新了openAPI文档,如果您有兴趣的话,可以参考最新的文档。

关于调整大陆地区MSS定价的通知

关于调整大陆地区MSS定价的通知

由于近期外汇汇率的大幅波动,我们考虑在本月底或者下月初的时候,调整大陆地区miniSIPServer软件的定价。调整基准将依据外汇汇率:1美元换6.5人民币,因此产品价格变更为“国际通用美元定价*6.5″作为大陆地区人民币定价,新的定价将高于目前已有的价格。

美元定价保持不变。

MSS之间采用SIP中继通信

MSS之间采用SIP中继通信

1. 描述

部分客户在多地都有分支机构或者分公司,因此希望在这些分公司之间建立VOIP连接。有很多种方法可以实现这个需求,本文给出一个具体的实例描述两个MSS之间采用SIP中继建立这种连接。

2. 网络拓扑

整个网络拓扑结构是比较简单的,总共只有两个分支办公室,各部署一套MSS。如下图所示:

网络拓扑
网络拓扑

在部署VoIP网络之前,我们应先做好号码规划。不同的号码格式或者规划直接影响到后期的呼叫路由配置。在上图中可以看到:我们给分支1规划的号码是1xx格式,例如100、101等,而给分支2规划的号码是2xx格式,例如200、201等。

两地的MSS都配置了公共IP地址,能直接连接公网。如果您的MSS是部署在私网或者路由器后面,并且您希望也能向外部用户提供服务,请先点击文档了解细节。

现在我们开始本场景的具体配置细节。

3. 配置

在下面各项配置中,如果没有特别申明,部分参数总是采用默认值即可。

3.1 MSS1

请点击菜单“数据 – SIP中继”,添加以下记录:

SIP中继编号 = 1
描述 = to MSS2
服务器地址 = 10.23.x.x

请点击菜单“拨号规则 – 分析被叫号码”,增加以下记录用于MSS将呼叫路由给MSS2:

被叫号码前缀 = 2
路由类型 = SIP中继
SIP中继编号 = 1

3.2 MSS2

基本配置与MSS1几乎相同。

请点击菜单“数据 – SIP中继”,添加以下记录:

SIP中继编号 = 1
描述 = to MSS1
服务器地址 = 41.32.x.x

请点击菜单“拨号规则 – 分析被叫号码”,增加以下记录用于MSS将呼叫路由给MSS1:

被叫号码前缀 = 1
路由类型 = SIP中继
SIP中继编号 = 1
新年快乐!

新年快乐!

2016年就要来临了,祝大家新年快乐!万事如意!

在这喜庆的时节,我们将miniSIPServer长期版本升级到V24,稳定版本升级到V25版本,这是今年最后一次升级,也是一次非常重要的升级。

祝各位朋友假期愉快!

同时也希望您重返工作时能喜欢我们的新版本!:-)

优化SMTP库

优化SMTP库

在“语音邮箱”业务中,MSS需要采用SMTP库发送语音邮件。考虑到MSS本身支持嵌入Python脚本,因此很容易就直接调用python-smtplib库发送邮件。这正是我们在以前的版本中的实现方式,一直工作得很好,我们也很满意。

然而smtplib库(python2.7携带)有点过时了,无法满足一些现代SMTP服务器的要求。另外,该库也有一个明显的缺陷:它是同步方式。这意味着发送邮件的过程中,会阻塞业务线程,导致性能低下。这在普通PBX应用场景中不是问题,但是在我们的云端通信系统中就显得不太合适了。

事情已经发生改变,我们也希望MSS能更加完美,因此决定开发一个新的SMTP库来发送邮件。新的SMTP库采用异步方式,有更高的性能,符合现代SMTP的各项要求。并且,采用C/C++语言实现。

我们已经更新了V23版本和云通信系统,都采用了最新的SMTP库。希望您能喜欢最新的版本。

另外,自从V23版本发布数月以来,我们得到的反馈非常之好,因此我们想是时候发布新的长期支持版本(即V24版本)以及新的稳定版本(即V25版本)了。按照版本计划,如果没有意外的话,我们将在今年年底或者明年年初完成上述版本的升级,敬请期待!