Browsed by
Category: 工作

奇怪的需求

奇怪的需求

工作中经常会遇到客户提出各种各样的需求,有些需求很合理,有些需求很有难度,有些需求则让人摸不着头脑,比如今天遇到的一个需求。客户的需求看上去似乎不复杂:

呼叫离线(offline)的被叫用户时,先 push 一个通知(notification)给被叫用户,收到响应后再发起呼叫。

我推测这位客户可能在构建某个移动APP。移动APP经常遇到的问题是:希望常驻后台,但是手机的电源管理往往会优化掉应用。这导致该移动APP会强制退出运行,从而无法正常接收消息、更无法接收呼叫。

客户提出的需求不应该是这个场景的解决方案。应当是APP自身向系统申请足够的权限驻留内存,并且APP应该和 SIP 服务器定时 keep-alive 保持激活状态。前者是APP自身的设计问题,后者是SIP注册、激活问题(标准流程)。

当然这只是我的个人推测,不太适合直接反馈给客户,因此向客户简单地提示了几个问题:

(1)离线状态下,怎么保证收到 notification 呢?

(2)既然可以收到 notification, 为什么就不能收到 SIP 的呼叫消息(INVITE)呢?

2020-10-12 更新: 稍微了解了一下相关的内容,大概是 iOS、Android 提供了统一的通知机制。如果收到了 notifications, 系统会从后台启动程序,这样 SIP 终端又可以重新注册并接收呼叫了。 这种模式当然是可以工作的,不过方案确实也很丑陋。另外,由于 GMS 在大陆已经不可描述了, 因此大陆的 Android 手机就更奇葩一些,通过应用程序链之间互相唤醒、互相调用(脏得一批 ……)。

2020-11-28 更新: RFC8599 定义了 SIP PUSH NOTIFICATION 的规范,对于移动终端 APP 类的 wake up 机制进行了定义。还不清楚该规范的应用情况,待进一步了解。

Cloudflare 返回的DNS结果

Cloudflare 返回的DNS结果

最近查一个客户遇到的 SIP 呼叫问题,发现在检查 DNS 记录时有问题,没有正确获取 DNS 记录。切换了几个 DNS 服务器测试,只有 Cloudflare DNS 服务器(1.1.1.x 系列) 返回的DNS记录会触发问题。

这并不是说 Cloudflare 的DNS记录有错误,而是我们自己实现的 DNS 库没有考虑到该记录的不同寻常之处。Cloudflare 的返回结果确实有点与众不同。

下图是Google DNS 以及 Ali DNS 返回的DNS结果,请注意其中的 Name 字段的内容(0xC0 0x0C)

Google DNS 结果
Google / Ali DNS 返回结果

很明显,这种DNS结果采用了 compress 方式,通过 offset 来获取真正的Name。图中的 0x0C 实际就是偏移量,指向了包中的另一处地址。Compress 方式最直接的好处就是节省了包大小。

而 Cloudflare 的 DNS 结果如下图所示,直接将域名包含在 Name 中,以 0x03 标注开始,以 0x00 表示字符串结束。不再需要偏移指向其他地址。

Cloudflare 的 DNS 记录
Cloudflare DNS 返回的结果

这种方法的好处是够直接,不再需要跳转获取真实的域名信息。当然坏处是增加了数据包的大小。

我们测试了网络上大部分的 DNS 服务器,目前仅发现 Cloudflare 采取了这种方式,其他服务器都是采用 compress 方式。

站在“人”的体验角度,似乎 Cloudflare 更合理一些。但是要注意,compress 方式更符合计算机的处理,毕竟前面的 Queries 部分已经解析过 Name 了,没必要再解析一次。另一方面,直接 offset 寻址,也远远快于再一次通过判断0x00来解析Name 字符串。

因此我个人认为 Cloudflare 的处理方式,即拖慢了速度,又增加了数据包消耗。当然,以目前计算机的处理能力以及网络速度,这些都是浮云。我们的解决方式也是淡定地接受这个结果,并修改 DNS 库进行适配即可。

在本次查问题中,测试了网上公布的香港 DNS 服务器,全部拒绝了来自大陆 IP 地址的 DNS 请求,真有意思。

迁移系统至SSD盘

迁移系统至SSD盘

日常工作是使用一台Thinkpad T430,有点年头了,感觉各方面都已经有些吃力。很早就想着将系统转到SSD盘上,但是又不想重装系统,毕竟是正在用的工作电脑,折腾不了那么多时间。

这事就这么搁置下来了……

近日在逛知乎的时候,发现了一篇文章(请点击此处),里面介绍了免费软件可以轻松迁移系统到SSD盘上。大喜之下,从京东购买了msata接口的金士顿 SSD 盘(UV500系列,请点击此处了解),同时从文章中下载了软件,准备进行迁移。

遗憾的事情发生了,文章提到的免费软件已经不支持迁移系统,需要付费才行。后来在网上发现了其中文版本“傲梅分区助手”(请点击此处),似乎是同一厂家的软件。中文版本需要关注公众号,然后从公众号拿到注册码, 免费 ,而且功能上可以迁移系统,耗时大约两小时左右。

过程稍稍有点折腾,不过如果是三星的SSD盘的话可能就省事,因为三星提供了免费系统迁移工具,当然只对三星的SSD盘有效。

迁移过程比想象中简单多了,以前的软件多数都是安装在系统默认的C盘,因此直接就迁移过去了,非常平顺。部分软件安装在其他盘符,在新系统中调整一下盘符,或者卸载部分软件再重新安装即可。

总之,工作量不太大,过程顺利,很满意。

Google AdWords 一点小经验

Google AdWords 一点小经验

古语有言:酒香不怕巷子深,然而今时今日这种观点已经过时了。好的产品如果不为人知,即对不起开发商自己,其实对消费者也是损害。好的产品就应该广而告之,让大家尽早享受,摆脱折磨,比如我们的产品(miniSIPServer)就挽救了很多迷失在 Asterisk、FreeSwitch 中的灵魂。

常见的广告手段无非是:

(1)传统方式。例如在电视、纸媒、报纸、杂志等撒钱做广告,这种方式适合有钱的主,对一般中小企业而言,这种方式的价值越来越低,尤其对我们这类小软件开发商而言,几乎毫无意义。

(2)网络搜索广告。作为中文用户,我们一度以为首先应该试试百度的广告推广方式,当然后来发生的一些事件以及我们自己的体会而言,建议放弃百度,不要抱任何幻想。本文推荐使用Google AdWords。 当然,由于众所周知的原因,您需要自行解决访问问题。

使用 AdWords 的经历积累了一点经验,“广而告之”的“广”有几个方面需要仔细考虑:

(1)人群。是不是所有人都适合点击、接受您的广告? 实际是要对自己的产品有准确认识。比如我们的产品是企业软件产品,那么一般的消费群众就不可能是目标客户,向他们提供广告就没有意义。

(2)地理。是不是需要向全球提供广告?这点其实也和产品本身的定位有关联。这里有个常见的误区:“应当尽量拓展新用户! 如果某个地区客户少,更应该加大该区域的广告推广!”。 如果您的客户大部分来自某个区域,那么向那个区域推广告其实更可能取得比较大的效果。比如我们的产品客户绝大部分来自欧美,因此我们在AdWords中,限制了广告的【地理范围】,只设置定位在欧美地区,基本上将广大亚非拉地区明确排除了(若干发达经济体除外,例如香港、新加坡等)。就我们的经验来说,亚非拉地区的欺诈性点击很多,对产品的推广毫无帮助。

(3)方式。AdWords 提供了很多推广告方式,例如搜索方式(这个最常见)、联盟网络推广等。我们可以明确的是:只要选择搜索方式即可。联盟网络推广等方式虽然能增加点击,但是帮助不大、欺诈也多,用户也可能只是看到广告,随手点击来看看而已,这类广告带来的用户往往并不是产品的目标客户。而通过搜索推广告,这契合了用户的搜索需求,极可能就是您产品的目标客户。

(4)关键词选择。通常我们都希望尽可能将所有的关键词都加入进去,哪怕只有一点点关联性的关键词也恨不得全部加入进去。这在初始阶段当然可以。运行一段时间后,需要观察关键词的效果,如果点击率小于1%,那这个关键词就应该放弃。有时候我们自认为某个关键词高度契合产品,实际搜索结果往往会大跌眼镜,这种情况下要果断砍掉,别犹豫。

(5)费用。不差钱的主可以忽略。如果费用预算有限制,自然需要精打细算。必须限制每个广告系列、默认每次出价的最高值。在这点上,不要相信 AdWords 的调价建议,这些建议基本是按照最高出价进行调整,如果盲目地跟随这些建议,您的广告费用就会直线上升。默认出价值仍然应该根据关键词的效果来调整,确保您希望的关键词能有合理的点击率。广告费用应当与您的产品销售收入要保持一致,过高的广告投入未必会换来产品销售增长。

市场分析后的迷思

市场分析后的迷思

最近不太忙,于是花了点时间研究一下我们云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网站后,内心有些平衡。太丑了!这么丑的网站都有如此之高的人气,可见“内在比外表重要“还是很有道理的。