Browsed by
Tag: freeswitch

3cx收购了elastix

3cx收购了elastix

原始新闻链接请点击此处。从新闻内容大致可以得出以下结论:

(1)Elastix V5的内核从Asterisk迁移到3CX。考虑到3cx是商业、不开源的版本,因此elastix从V5版本开始应该就会转向闭源。

(2)以前的Elastix版本,例如使用比较广泛的V2版本,以及充满了bug的V3和V4版本,依然遵循开源协议。相信这些旧版本的用户无法免费升级到V5版本,需要付费购买产品或者购买技术支持才有可能。

(3)3CX可能看重的就是elastix目前已有的大量用户,希望能从产品技术支持、付费购买等途径获得利益。

国内一些专业QQ群里有部分用户表达了对这件事的愤怒情绪,感觉自己被Elastix背叛了。仔细搜索了相关报道和各类消息后,我有些不同的看法。对Elastix项目而言,『被收购』是个不错的商业选项,项目人员获得合理的报酬完全是可以理解的,毕竟这是个商业社会,人不能光靠理想一穷二白地活着。

相反,我对3cx的收购决定感到困惑。Elastix是个不错的项目,也有很多拥趸,但究其根本,依然只是依附在Asterisk上做了个壳而已,这也就意味着客户的迁移成本实际上并不高,客户完全可以从一个壳转另一个壳,比如FreePBX。实际上很快就发现FreePBX在twitter等社交媒体上发帖欢迎Elastix用户进行迁移。

由于这些壳都是使用Asterisk作为核心,因此配置规范(接口)、管理接口实际都遵循Asterisk定义。从Elastix转换到FreePBX,相信比转换到3cx要简单、容易得多。从这点看,我很怀疑Elastix用户会如3cx所愿地迁移到3cx的平台。如果不能顺利完成这种转换,这次收购的价值就会大打折扣。

目前市面上有各种各样的软、硬件PBX,绝大部分其实都是基于两个开源项目:Asterisk和FreeSwitch,差异化无非体现在各种定制化的包装。如果想获取最大利益,应该是直接收购或者控制这两大项目。如果说“条条大路通罗马”,那Elastix、FreePBX不过是其中两条路而已,Asterisk/FreeSwitch才是目的地罗马。与其在道路上设卡收费,不如直接控制罗马。

从这个角度考虑,所有基于这些开源项目的软、硬件产品实际上都有风险。一旦项目被收购,产品就有被扼杀的危险。避免此类危险的唯一路径,大概就是控制住这些项目,或者另起炉灶。

幸运的是我们的产品(miniSIPServer)是完全自主开发,与这些项目毫无关系,因此不存在任何法律和潜在的风险,这也使得我们能够完全掌握自己产品的发展,从而为客户提供安全、可靠、一致、长久的体验。

希望这些开源项目能长久繁荣下去,毕竟一起做大蛋糕、做大市场对大家都有利。

并发数

并发数

QQ群中有几位朋友在聊呼叫系统性能的问题,默默地观察了一段时间,感觉大家对一些基本的技术术语其实都没有澄清,比如并发数。

“并发”一般理解为“同时呼叫数”,很多朋友往往将ta误解为“同时试呼数”。“并发呼叫”英文术语是Concurrent Calls(CC),而“同时试呼数”英文术语一般是Calls per second(CPS)。从英文的意思来看其实就更明白一些。

CC和CPS都是衡量呼叫系统性能的重要指标,两者也有一定的联系,这涉及到另一个术语:平均通话时长。通常情况下,根据统计结果,一般呼叫系统中的平均通话时长大约为100秒。当然某些通话时段(例如晚间)、某些特殊人群(比如爱煲电话粥人士)的统计结果有很大差异,但就总体统计而言(尤其是企业通信领域),“100秒”是个相当有代表性的统计结论。

假如“平均通话时长”是100秒,那么CC和CPS的关系就是:CC = 100 × CPS。

例如,有位朋友要求系统能支持100个并发呼叫(CC=100),那么CPS只要1(CPS=100/100)就可以了。也就是每秒只需要支持1个呼叫,这对大多数呼叫系统而言都能轻松支持。

而如果要求能支持到每秒100个呼叫(CPS=100),那么系统资源就必须按照10000(CC=100×100)并发呼叫的容量去设计和考虑。这实际已经是中型呼叫系统的指标了,绝大多数基于Asterisk或者FreeSwitch的小型呼叫系统如果不做特殊修改或者定制,不可能支持这个性能要求。

在没有弄清楚CC和CPS含义的情况下,胡乱提要求或者回答问题是会闹笑话的。比如QQ群里一位大侠吹嘘自己呼叫系统的性能指标,按照上述计算公式,居然可以支持到3亿并发呼叫,也就是说只要四套这个系统,就可以让全中国的人同时打电话!

差点被吓死了。