在做梦吗？
最近实在是受够了。网络被TM地封得没法用，看看下面随便ping一下的结果：
数据包: 已发送 = 246，已接收 = 170，丢失 = 76 (30% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 301ms，最长 = 1520ms，平均 = 331ms
纯技术网站都封，创个屁新啊！大家都去做梦好了！！
大户型路由器
第一次听到这么个说法，感觉很新奇。于是进一步了解了详情。新闻链接请点击这里。
所谓大户型路由器就是信号超级强，以至于隔着几层楼都能有极好的信号。周老板兴致勃勃地说：在我家三楼别墅都能收到信号哟！
差点笑喷！大哥，路由器信号加强了，笔记本、手机等终端的信号怎么解决啊？路由器怎么收三层楼上各类终端wifi信号啊？难不成将笔记本或者手机也改成大户型笔记本、大户型手机？
不是周老板忽悠大家，就是有钱任性被人给忽悠了。
XP遗留软件的新选择
收到一位印度朋友的email，特意感谢我们的软件。他是在一个奇怪的场景中运行MSS：系统是Ubuntu14.04，通过Wine运行MSS。我感觉很好奇，因此和这位朋友聊了聊，内心颇为感慨。
这位印度朋友在一家生产工业控制类产品的公司工作（从公司名字看，貌似和西门子有一定联系），他在windows XP上搭建了一系列软件，有自动控制的、有远程访问的、有各类服务器软件，包括PBX软件。不过以前是采用Asterisk Now做PBX。微软不再为XP提供服务后，他们开始寻找替代方案，并着手将上述各类软件转移到Ubuntu系统，通过Wine来运行。
毫无疑问，wine是个活跃的社区，因此基本可以放心在未来的一段时间内能继续使用现有的XP系统的软件。移植过程很顺利，然而在Astersk Now上被卡住了。这个软件居然没法在wine上运行，而且项目本身似乎已经很久没更新了。他们花了很长时间尝试其他各类软件，都有各种各样的问题，直到运行miniSIPServer，一切都很顺利，系统很稳定。因此特意写了email来表示感谢。
首先让我感慨的是，有人因为软件好用写邮件表达感谢。
其次感慨的就是，印度朋友居然都已经非常尊重软件版权以及软件开发者了。我们国家的做法是先臭骂一顿微软垄断，然后屁颠屁颠地装个360，或者下个盗版的win7/8接着用。
印象中，我还没听说国内有谁采用wine来维护遗留系统。这无疑是个很好的想法，非常值得肯定。如果您有类似的遗留系统要维护，不妨也试试wine。同时我也想向wine开发团队致敬！有兴趣的话您可以访问其官方网站进一步了解：
统计代码行
在Debian系统中可以很轻松就统计出代码行，无需另外安装软件，默认的就可以。例如，可以使用下述命令统计当前目录及子目录下cpp文件代码行数：
find . -name *.cpp | xargs wc -l
今天稍微统计了一下MSS的cpp代码行，居然已经突破10万行，突然之间有些时光的恍惚感。
Debian7只识别出一个CPU
昨天无意间进入T410笔记本的BIOS设置，惊讶地发现居然支持CPU虚拟化，只是默认关闭了。打开设置后启动系统，进入VirtualBox，果然可以对每个实例设置多CPU、PAE以及APIC等。
修改上述设置，增加了一个CPU，启动Debian，居然还是只识别出一个CPU。貌似vbox没有起作用。纳闷之下，同样修改了另一个ubuntu实例的设置，启动后能正常识别两个CPU。因此判断还是Debian实例有问题。简单google了一下，貌似是内核需要启动SMP（Symmetric Multi-Processors）功能。
进入Debian后做了一点检查，原来默认采用的内核是image-486，非常保守。重新安装pae内核，即可启动SMP功能，识别出多个CPU。命令很简单：
apt-get install linux-image-686-pae
安装完后，重启debian实例即可。如果主机是windows系统，则可能还需要重新安装virtualbox-guest-dkms，执行以下命令即可：
apt-get remove virtualbox-guest-dkms apt-get install linux-headers-686-pae apt-get install virtualbox-guest-dkms
香港大学生要求重启南京条约？！
来自新浪的新闻链接，点击此处。
让人非常惊讶，甚至震惊。香港大学生对中国的认识和理解偏差实在是到了让人难以理解的地步。对中国和英国关系的理解还停留在清朝？这是脑袋被驴给踢了吗？
新自贸区
早上看新闻，貌似要在深圳前海开新自贸区。这个消息还是比较吸引人，尤其是我离前海还是比较近的。
希望深圳这个自贸区能有些不同，能有些让普通老百姓实实在在感受到的进步。对比之下是上海的自贸区，发展到现在，广而告之的成就似乎是以下几点：
（1）游戏机终于可以进来了。
（2）上海老百姓能在自贸区内买到便宜的海鲜产品。
（3）豪车可以直接进来了。
（4）貌似海淘海外产品要便宜一些了。
然后就没有了。上海自贸区到底是干吗的？当初创立时，香港人很紧张，我觉得现在港胞们可以长舒一口气了。
多线程调试的一点技巧
最近几天遇到一个问题，程序在客户的虚拟机中跑了几分钟就不响应了。这实在是很无厘头的一件事情，因为在实体机以及相同配置的虚拟机里，居然无法重现这个问题，而客户几乎每次都重现。
问题本身不复杂。SIP协议栈收到SIP消息后，产生内部数据放入队列，同时通知UA进行处理。诡异的地方在于：UA层居然没有任何反应。初步判断是线程挂住了，可是不知道是什么原因导致的。于是乎各种修改、各种debug、各种打印都用上了，始终不得其解。
google了相关主题后发现其实也挺简单，使用gdb就可以（原谅一个一直使用IDE的人吧），比如程序名是mss：
（1）查找mss当前的pid：ps -A | grep mss
（2）假设pid为1234,则使用gdb调试：gdb mss 1234
（3）进入gdb后，使用bt命令即可查找当前堆栈情况，了解程序卡在什么位置。
（4）也可以使用info threads了解程序各线程的状况。
太贵了
这几天心情不太平静，总有一点小感慨，尤其是临近年末，又有些回想的味道。
先回顾一下产品（单指miniSIPServer而言）今年的销售情况，毕竟是年末了嘛。今年在大陆地区的销售比去年好很多，但是我仍然非常沮丧地发现：还不够好。“不够好”到什么程度？以亚洲地区为例，大陆地区的销售额甚至远远低于泰国。是的，你没有看错，泰国！为此我特意google了一下泰国：中国人口大约是13亿，泰国人口大约是6700万，也就是大陆的1/20人口。
这实在是个让人感觉很纠结的结果。网上（QQ、email等）和一些客户有些交流，普遍反馈：产品是不错，就是太贵了。这就让人更纠结了。同样以泰国为参照，所有订单都来自我们的英文网站，也就是说客户是按照国际统一价格购买。而中文网站里的标价比英文网站至少优惠了20%。
而英文网定价与业界同行相比，都极具性价比优势。这点从各地用户的反馈信息来判断，我们还是很有信心的。因此“太贵了”究竟是与什么比较而言呢？我个人判断是和免费的各类产品比较，比如freeswitch、asterisk等。此类产品先不论品质如何，至少需要花费大量的时间和精力去学习和了解。从我加入的几个QQ群也可以看到，大量的问题都是一些配置方面的问题，而如果采用miniSIPServer，这些根本就不是问题，或者说只需要点点鼠标就能搞定的事，完全不需要花那么多时间。
单纯追求产品的免费是毫无意义的。时间成本、维护成本等后期成本也是需要考虑在整个成本当中，而朋友们似乎更关注产品的一次性购买成本。如果是专业人士也就罢了，可以花费时间和精力去学习、掌握这些开源的系统，甚至可以定制系统。而如果仅仅是一般使用者，有这个必要么？有这个时间和精力，为什么不花在更有价值的地方呢？
优质的产品（无论是软件还是硬件）都应当值得合适的价格，而我们也将一如既往地追求产品的高品质。新的一年也希望有机会更贴近客户，提供更合适的产品，取得更好的成绩。
2014-12-11 updated: 感觉自己有点矫情了。价格固然是个重要的因素，更关键的应该是产品还没有抓住客户的痛点。客户在比较时，可能会觉得，这个产品虽然不错，但是其他产品也有这功能，无非就是花点时间而已。
webRTC调试方法小结
前段时间完成了miniWebPhone V1版本的开发，基于Chrome浏览器，采用了webRTC技术。在开发过程中，发现其实webRTC技术使用起来还是不太方便，有很多让人感觉很困扰的地方。基本上只有VoIP领域专家才能明白诸多操作以及参数的意义，即便是这样，仍然需要根据Chrome的输出信息来了解Chrome中webRTC的各项细节。
有几种方法可以了解webRTC过程中的细节信息。
方法1：chrome://webrtc-internals/
这个方法是最简单的。在Chrome地址栏中输入上述命令，即可了解webRTC的过程。不过这种方法输出的信息非常粗略。如果您对webRTC很熟悉，那么可以从中了解一些有用的信息。如果您对webRTC不熟悉，那TA的信息您肯定看不明白。
方法2：chrome日志
这种方法我经常使用，而且推荐在linux环境（例如Debian）中使用。实际上，我不知道windows系统下如何看Chrome的日志。Chrome的日志很详细，基本上会输出每个步骤详细的信息。
在linux终端窗口用以下命令启动Chrome即可：
google-chrome --enable-logging=stderr --log-level=4 --vmodule=*libjingle/*=3,*=0
方法3：Chrome源代码
日志可以帮助我们了解大部分webRTC的细节，但是webRTC某些实现仍然是有问题或者说让人困扰的（例如对ICE的处理主、被叫流程不一致，错误处理没有输出日志等），此时直接看代码就是比较好的解决方法。完全、彻底地阅读Chrome是个不可能完成的任务，只能结合Chrome日志去追踪相应的代码。