双非儿

双非儿

早上在新浪看到一篇双非孩子上学的报道，顺便也看了评论区的评论，内心五味杂陈。

是的，我们家里老二（苗苗）也是一位双非儿童，所以我非常理解报道中家长的心情和困窘，同时也对评论区的一些冷血评论感到愤怒和悲哀。我已经一把年纪了，经常告诫自己不要太执着、不要太生气，什么事情都要看开点，但这些风言风语实在压抑不住自己的心情。

为什么要去香港生孩子？深圳南山各街道办超生罚款三十几万人民币，去香港生只需花费几万港币。这就和奶粉一样，一个有三聚氰胺，一个没有三聚氰胺，这些都是不难做出决定的选择。

网上“占深圳便宜”的言论，让人极其愤怒！我们每年都交十几万的税，养老金也是自己交，究竟谁占便宜了？更重要的是，一个国家、政府甚至人民，居然视自己的孩子为累赘、负资产，亘古未有！怎么去教育这些”不应该存在的”孩子去爱这个国家？

我要特别感谢香港政府！当初要是没有香港，我们就不会生下苗苗，现在也会少了很多的欢乐。虽然现在有陆港矛盾，有诸多限制，香港政府至少还是采取了一些措施（当然，其中部分措施涉嫌歧视，同样让人反感），考虑了双非家庭的特殊情况。对比之下，我实在不想对内地再多说什么了。

我对强国梦之类的东西没太多理解，也不感兴趣。我唯一能做的是尽力养活自己的家庭，让孩子们健康快乐的成长。如果将来苗苗能看到这篇blog，我希望她首先要感谢自己的妈妈，要是没有妈妈的坚持，她不会来到这个世界。另外，我也希望她长大后能为香港做一些贡献。

如果说我对内地还有一些期许的话，那就是少一些戾气、多一点人性，少做一些梦、多干一点实事。

解决DNS污染

解决DNS污染

DNS污染可能是一个比较普遍的问题，主要表现在：（1）DNS查询返回的IP地址根本是错误的。“错误”意思是IP地址要么根本不存在，要么就是个和域名完全无关系的地址。（2）IP地址虽然可能是对的，但是其他参数被莫名修改，例如TTL参数等。

测试了各类DNS服务器，例如阿里DNS、DNSPod（鹅厂）、Google DNS等。无一例外，最终的结果都或多或少被一些看不见的手给修改、甚至屏蔽了。从技术角度上讲，DNS协议本身非常随意、非常粗糙，是典型的互联网蛮荒时代的产物，比如面向UDP、无加密、无鉴权等，因此网络上任何一只手都有可能修改DNS的查询结果。网络进化到IPv6阶段，当然能解决这个问题，不过既然目前绝大部分设备还只支持IPv4协议栈，因此我们还是不得不修修补补来解决这个污染问题。

最根本的解决方法就是加密DNS查询。目前有些DNS服务商提供了私有的加密DNS方式，不过不太通用，需要私有的客户端程序配合。实际上可以不用搞这么复杂，自己建立加密通道，传递DNS消息即可。例如，参考下图的拓扑逻辑：

实现简单DNS透传的逻辑单元
实现简单DNS透传的逻辑单元

在这个网络中，有两个关键程序：dnsProxy和dnsAgent。

dnsProxy顾名思义就是个Proxy，本身并不负责DNS协议的解析，也不保存DNS的查询结果等信息，只是单纯地将DNS消息传递给真正的DNS服务器，并返回相应的结果即可。dnsProxy另一个功能是对外提供加密的数据连接，例如TLS、SSL加密等，甚至可以只是简单地对数据包进行自定义的异或运算即可。另外就是对外提供非标准连接接口，这点非常重要。DNS采用标准UDP53接口作为DNS服务器接口，网络上那些看不见的手，往往就是扫描并篡改53接口的数据包。这个小程序跑在境外（大家都懂的）的一台VPS设备上，推荐采用DigitalOcean，专业的云计算服务商，采用SSD硬盘，价格公道，我们一直用TA，如果你有兴趣的话，请点击这里自行了解细节。

dnsAgent是另一个小程序，主要负责建立与dnsProxy的加密连接，接收普通设备的DNS请求并将其传递给dnsProxy，同时返回DNS结果给普通计算设备。对于网内设备而言，dnsAgent就是个伪装的DNS服务器。同样，dnsAgent其实也不需要关心、也不需要解析DNS协议细节。在我的网络中，dnsAgent跑在一台常年吃灰的树莓派上（还是第一代的）。

实现这些仅仅需要一点UDP、TCP的网络知识，甚至不需要了解DNS协议的细节，无需对DNS数据包做修改。完成后可以愉快地打开很多以前打不开的网站。当然，有些网站始终是打不开的，这是另一个与DNS无关的话题了。

Pi打开IPv6

Pi打开IPv6

默认已经安装了IPv6协议栈，但是没有打开IPv6功能，这点比较奇怪。不过打开IPv6功能也不复杂，一行命令即可：

sudo modprobe ipv6
市场分析后的迷思

市场分析后的迷思

最近不太忙，于是花了点时间研究一下我们云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都在此次寒冬中濒临破产，其他通信行业同行（包括我们）毫无疑问都要提高警惕，谨慎行事。

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

v2ex

v2ex

我曾经很喜欢进这个网站（论坛），因为TA很自由，很小清新。

而最近却感觉厌倦。V站充斥着果粉、道德洁癖以及以及各色圣母婊。V站站长Livid似乎想以一种想象中的道德尺度来衡量会员。不能说这有什么错误，只是我认为没有什么唯一性的道德尺度，也没有什么人能充当道德标杆。当站长快意地进行评判、屏蔽言论甚至封杀会员的时候，我认为他已经和他反对的没有差别，无论他的理由听起来有多么高尚、多么合理。

V站的这种伪善让人乏味，回想每天手工签到，更是病态。

6to4 tunnel

6to4 tunnel

今天无意中发现，居然不用翻墙就能打开google和gmail，这简直太不科学了，我朝气象从此焕然一新？

本着“怀着最大的恶意揣测他人”的精神，我对此充满疑虑。于是拉出wireshark仔细dig了一下，发现了IPv6数据包，竟然是通过IPv6访问google和gmail！墙没有封锁IPv6，这实在是个惊奇的发现。

难道电信已经开始部署IPv6网络了吗？对此同样充满疑虑。但是有一点是肯定的：最近买的路由器是支持IPv6的。进入路由器管理界面，发现电信仍然是分配IPv4地址，但是在路由器IPv6设置项中，配置了“自动检测IPv6类型”，检测结果是“6to4 tunnel”，而且配置了IPv6地址。

看起来电信的确升级了网络，但是仍然没有真正部署IPv6，还在半遮半掩中，并且猥琐地限速了。有“6to4 tunnel”也还好，至少能访问外部IPv6的服务器地址。google和gmail等都部署了IPv6，因此可以通过IPv6来访问这些服务。而对于没有部署IPv6的服务，例如twitter之流等，依然还是无法访问。

不管怎样，这已经是向前迈进了一步。真心希望步子能迈得更大些！

2016-03-10 更新：好吧，我承认我还是图样了。

Pi3开卖了

Pi3开卖了

第三代树莓派正式开卖，感觉改进很大，值得入手。最吸引人的除了CPU升级为64位ARM外，还有就是内置WiFi！想当初为了支持USB接口的WiFi，那是一顿折腾啊，Pi3就省事多了。

话说现在手头上还是Pi一代（model B），用起来一直很稳定，相当具有可玩性。

新闻链接：https://www.raspberrypi.org/blog/raspberry-pi-3-on-sale/

 

 

为什么放弃了webRTC？

为什么放弃了webRTC？

首先必须要说明的是：webRTC是非常好的技术，以至于我现在仍然在怀疑，放弃webRTC是不是个明智的决定，内心依然是忐忑不安。

然而现状就是将webRTC从MSS新版本中砍掉了。下面试图说明清楚做决定时的一些考虑。

从webRTC技术的发展脉络看，感觉ta更适合于公共网络的通信，尤其是越来越像专为google hangouts服务。由于是服务于公共网络，因此“加密”提高到一个非常重要的位置，几乎达到了神经质的地步。webRTC设计之初就没有考虑过传统的VoIP网络（尽管该技术来自于收购的GIPS团队，而该团队本身就是为VoIP网络开发出身的），从传输到业务，基本都特立独行。当然，这没什么不好，只是由于与传统VoIP网络切割开来，实在让人经常感到惋惜。

既然没有考虑传统VoIP网络，当然就更不可能考虑网络部署的多样性。全方位加密固然让自己显得安全，带来心理上的安慰，但也增加了网络部署的复杂性（VoIP本身已经够复杂了）。就一般的VoIP应用而言，“salt+MD5”以及SRTP已经足够保证通信的安全性和私密性。而最新的webRTC（不特别说明的话，这里我们总是指Chrome的webRTC实现）要求getUserMedia等操作必须是来自加密（HTTPS）的网站，websocket也必须进行加密。这也就是说，用户必须要为webRTC服务器（通常也是呼叫服务器或者IPPBX）部署单独的签名加密（TLS或者SSL）。对于提供公众服务的网站而言，部署TLS/SSL不是太大问题，而要求中小企业申请签名并部署在呼叫服务器中，这毫无疑问极大地增加了系统的复杂度，增加了部署难度，而且这样做的意义又有多大了？在企业通信网络里与其这样增加复杂度（网络复杂度和管理复杂度），还不如干脆直接建立VPN网络，方案很成熟，加密更全面，保护更周到，方式方法也简单得多。

这就是我们感觉webRTC只适合公众网络并且已经神经质的原因之一。何况，“加密”有时候更多的是个管理问题而不是技术问题。

webRTC另一个宏大的目标是提供各平台统一的用户体验。愿望是很美好的，但是是否能实现值得商榷。把所有的处理都放入浏览器，固然增加了可移植性，但最大的问题也就是牺牲了平台的独特性和高效性。比如在移动平台，webRTC的耗电量就明显偏高。而且在移动平台各种莫名其妙的设定，极大地损害了用户体验，比如播放ring-back tone，居然要求用户必须点击一个按钮才能继续（是我out了么？），这实在是太扯了。

而最被我们诟病的是兼容性。webRTC基本没有什么兼容性可言。按道理已经发布这么久了，多少应该在一些关键点上考虑一下兼容性，然而并没有。这对一个像google hangouts这样的网站来说，不是大问题，用户无非升级一下chrome好了。而对部署在许许多多用户voip网络中的PBX或者webRTC服务器而言，就是噩梦了。用户升级了Chrome，就必须同时升级服务器，如果不升级服务器，就必须降级Chrome。与之相比，microsoft对兼容性的考虑简直贴心贴肺。

这种对兼容性的唾弃有时候甚至直接表现在产品本身。比如当初的Gtalk，直接就放弃了，我们花费大量时间精力对接Gtalk，最后也是然并卵。对webRTC也会产生同样的顾虑。

webRTC当然有很多非常优秀的技术特点，比如源自GIPS的回音消除技术、超强的语音编解码技术等。思虑再三，决定还是不再跟随，砍了算了，以后再说吧。