Browsed by
分类:工作

市场分析后的迷思

市场分析后的迷思

最近不太忙,于是花了点时间研究一下我们云SIP服务的市场情况。结果很出乎意料,很多结论与我们的预想是完全相反。

做云SIP服务的初衷是来自一些客户的反馈:MSS最小版本都支持20部SIP分机,而有一部分用户的场景中没有这么多分机,因此购买一套MSS软件稍显浪费。另外,有一些区域的用户,比如中国大陆,认为软件贵了点,希望能更便宜一些。

因此我们做了云产品,预计大部分用户会创建少量的资源(分机、外线等),同时也希望能吸引一些不太愿意为软件进行投资的用户。

经过基本的数据分析,我们得出以下一些结论:

1、不愿购买软件的人更加不会购买服务

云SIP服务不仅仅是产品,本质上更是服务,我们维护着整个VoIP网络系统的稳定,检查各种失败呼叫的情况,为客户排忧解难等等,这些都是对用户非常有价值。而数据表明,云SIP服务的客户范围与本地MSS软件的销售范围是高度重合的,仍然是以欧美客户为主,我们期待的拓展客户并没有出现。

不认可软件价值的人,也很难去认可服务的价值。

2、欧美客户更愿意购买服务

我们原先预想:部分对价格比较敏感的用户会使用我们的云SIP服务,另外用户熟悉过我们的云产品后,感觉满意的话,可能更愿意在本地部署自己的VoIP网络。而实际情况是:

(1)对价格敏感的客户更愿意选择本地SIP服务器版本。这部分客户通常是非欧美客户。

(2)我们的很多客户是已经购买了MSS软件,尝试了云SIP服务后,反而将本地VoIP网络迁移到云服务上。这部分用户更看重稳定的网络和专业的服务质量。当然也有部分用户与我们的预期是一致的,最终购买了软件。这部分客户通常来自欧美地区。

3、价格不是关键因素

云SIP服务虽然每资源定价很低,但是如果设置大量资源的话,总体成本会逐渐超过MSS软件的成本,因此我们预期用户不会添加太多的资源,这样也与MSS软件形成互补。然而让我们惊讶的是:大量客户设置的资源数(分机、外线、语音文件等)居然超过20!跟踪分析了其中一部分长期用户的数据,结果发现这部分用户支付的费用足够买好几套软件了。

显然,对这些高价值用户而言,价格肯定不是关键因素,至少不是决定性因素。专业化的服务、稳定的网络、简单易用的使用体验才是吸引他们的关键。因此我们进行设计时,无需过多考虑价格,而更应该关注产品本身。

4、个性化需求还有待挖掘

首先说一下结论:我们极少遇到个性化需求。少数几个提出个性化需求的客户最终也没有成为我们的长期客户。

云SIP服务一个让我们自鸣得意的特性就是对IVR-XML以及Python脚本业务的支持。这个特性非常有利于我们为客户提供或者适配个性化的通信业务。我们甚至预期大量的客户会提出此类需求,比如不同的IVR流程等。然而现实就是“并没有”,大家都还是在使用默认的各种业务和呼叫流程,这有点让人郁闷,感觉辛苦努力的东西其实是屠龙之技。

这点结论可能值得商榷,还需要继续观察。至少我个人仍然认为多数企业对自己的通信需求都会有个性化的地方,目前这个结论可能是我们没有真正了解到客户的需求造成的,也可能是我们的客户群还不够广泛造成。

Aspect申请破产重组

Aspect申请破产重组

新闻链接:http://www.ctiforum.com/news/world/477928.html

消息很让人震惊!Aspect可以算呼叫中心软件行业的标杆性企业,微软企业通信解决方案的头牌合作厂家。全球同此凉热,如果连Aspect都在此次寒冬中濒临破产,其他通信行业同行(包括我们)毫无疑问都要提高警惕,谨慎行事。

希望我们能撑过这次的经济寒冬。

推荐一个MSC小工具:mscgen

推荐一个MSC小工具:mscgen

在通信设计中经常需要使用消息序列图(MSC),目前市面上有很多画MSC图的工具,例如UML工具,例如我们自己的一个小工具等等。这些工具都是图形画的工具,而现在要推荐的是mscgen:一个用文字描述然后产生MSC图的工具,能生成SVG、PNG等多种格式。

从该工具网站提供的描述看,语法很简单,很有意思,精确地抓住了MSC图的本质,朴实而实用,非常值得大家尝试使用。

37signals的两个重大改变

37signals的两个重大改变

37signals是Ruby界赫赫有名的公司,而我对她的了解来自于该公司创始人两本非常著名的书:getting real和rework。可以说,我实际上就是看完这两本书后,才决定走上创业道路的。

而今天该公司做出了两个重要的决定:(1)砍掉其他产品,只保留一个产品BaseCamp。(2)公司名也修改为BaseCamp,一切围绕BaseCamp。

这是让人非常吃惊的决定,同时也让人由衷地敬佩。保持对产品的专注,做一家小而美的公司,这也是我对自己、对公司的愿望。

悲催,电脑坏了

悲催,电脑坏了

使用了多年的笔记本电脑,今天居然不能启动windows,莫名其妙就crash了。经过了一个悲催的六月,七月一开头就整这么回事,是不是预示着一个更让人郁闷的七月?

幸好安装了linux双启动,还有挽回的余地。想办法折腾中。。。

丑得有性格的网站

丑得有性格的网站

我一直以为我们的网站大概是天底下最丑的网站,今天访问了著名的Hacker News网站后,内心有些平衡。太丑了!这么丑的网站都有如此之高的人气,可见“内在比外表重要“还是很有道理的。

 

SIP-INFO传递DTMF信号的若干约定

SIP-INFO传递DTMF信号的若干约定

采用SIP-INFO消息来传递DTMF信号,似乎只是Cisco的定义,没有一个成文的标准,但是目前主流的SIP厂家基本都遵循了相同定义,主要采用‘Signal’参数传递DTMF值:

Signal=1
Duration=160

其中,Signal与DTMF信号对应如下:

DTMF               Signal  
-------------------------
0--9        0--9
*          10
#         11
A--D        12--15
Flash       16

这种映射关系与RFC2833规范一致。但实际上,SIP-INFO既然是文本消息,其实没必要进行转译。例如,传递‘*’信号时,目前的处理是:

Signal=10
Duration=160

这样的定义非常不直观,完全可以直接传递,如下:

Signal=*
Duration=160

SIP-INFO这样传递显得非常直观。RFC2833二进制协议,只能进行定义转换,但是SIP本身是文本协议,足以进行文本性描述。可惜当初不知道为什么非要按照2833方式进行定义,也许这就是为什么这种方式始终没有成为正式规范的原因。

两周年了

两周年了

时间过得真快!从U公司离职,仿佛还是昨天发生的事情。

两年过去了,回头看看,自己真是在一个不太好的时间点选择了创业,非常鲁莽。这两年无论生活还是工作,都发生了巨大的变化,这些变化造成的压力有时候显得实在过于沉重。

希望接下来的日子会好一些。

SIP呼叫中的主叫号码

SIP呼叫中的主叫号码

传统电信网的各项规范往往经过了很多专家的讨论以及厂家的验证,因此显得比较严格和规范,例如传统的ISDN规范,定义都很明确。

而因特网的各项规范对比之下就显得很随意,往往是一个规范出来之前就考虑不周全,然后根据情况,又补充出一堆的规范。即使这样,仍然是显得有很多漏洞,或者说有很多不规范、不明确的地方,导致各厂家各说各的道理,给互联互通造成很大的困扰。

当然不是说传统电信规范没有漏洞或者定义含糊的地方,只是相比之下,因特网的规范实在是过于随意。

比如说SIP呼叫中的主叫号码。

在电信网规范中,与主叫相关的号码定义非常明确,主要就这么几个:主叫号码、原主叫号码以及显示号码。各号码的应用场景也非常明确,号码格式中的显示属性等也很明确。

在SIP规范中,与主叫相关的头域有这么几个:From, Contact, P-Asserted-Identity, P-Preferred-Identity, Remote-Party-ID等。这些定义要么没有明确规范好,要么就是多次一举,多半是RFC定义者遇到情况时,拍脑袋一想:算了,加个新的定义搞定吧。结果就让人很无语了。

From和Contact在标准的SIP code规范RFC3261中有明确定义,通常我们都认为From域中携带主叫号码,可惜规范并没有明确限定,因此有一些厂家往往在Contact域中携带主叫号码,而在From域中只携带地址信息。

而显然在实际应用中又遇到一些主叫号码显示的场景(估计主要是电信专家考虑3GPP网络的各项应用时,遇到了与传统主叫号码类业务的冲突),于是乎RFC3325规范就粉墨登场,一举增加了P-Asserted/Preferred-Identity两个头域,也是用来携带主叫号码信息。其中,P-Asserted-Identity主要在信任域的server之间、proxy之间、server与Proxy之间进行传递,而P-Preferred-Identity主要在UA与server/proxy之间传递。看,无聊不?折腾不?

而在正统的P-xxx-Identity头域出来前,民间的野路子显然也遇到了同样的主叫号码类业务的问题,于是乎定义了Remote-Party-ID,并基本参照了ISDN的一些定义,例如号码是否显示等属性,很多SIP厂商已经很high地支持了这个定义,比如说Asterisk。发现没?有了这个定义,还要P-xxx-Identity等定义干什么呢?但是不幸的是P-xxx-Identity已经是正式RFC规范,而Remote-Party-ID还停留在draft-xxx-04阶段(目前已经超时,不知道还会不会升级到正式RFC规范),因此SIP厂商不得不同时支持上述各个定义了。

我有没有提到:有些SIP设备在From/Contact等常见域中根本不携带号码,只在www/proxy-authorization中携带鉴权用户的号码,往往也就是作为主叫号码?

晕倒吧!

openssl一二事

openssl一二事

由于工作上的需要,最近两天折腾openssl来实现一些信令加密解密的事情。总体来说,openssl是个很不错的库,也是个很不错的工具。使用openssl做tls客户端编程没有太大问题,而实现tls服务器端则有些地方需要注意。

首先要注意的一点就是:在握手之前(SSL_accept),绝对不能采用非阻塞方式。握手成功之后,才可以将socket修改为非阻塞方式,否则握手不会成功,服务器总是会向客户端返回“Engypted alert”消息并结束握手。

如果是在windows环境生成证书和密钥,建议使用SimpleCA工具,很好用。同时要注意:(1)客户端应安装或者使用该工具生成的根证书,例如ca.crt。(2)服务端需要使用生成的服务端证书和密钥,即.crt和.key文件。(3)生成证书时(无论是根证书还是服务端证书),Common Name都必须要设置为当前服务器的IP地址或者主机名,否则双方握手时,可能产生”certificate name mismatch”等错误。(4)如果需要将证书导入windows系统,必须导入为“受信任的根证书颁发机构”类型。

如果是Ubuntu等linux系统,可以直接安装使用openssl生成证书,如以下命令:

生成根证书:
openssl genrsa -out ca.key 4096
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

生成服务端证书和密钥
openssl genrsa -out server.key 1024
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

理论上来说,可以将.crt和.key文件合并在一起,设置为.pem文件。不过实践证明,openssl的API是要求SSL_CTX_use_PrivateKey_file函数来加载密钥文件的,否则握手还是会出问题(当然,也可能是需要另外单独的设置)。