推荐一个MSC小工具：mscgen
在通信设计中经常需要使用消息序列图（MSC），目前市面上有很多画MSC图的工具，例如UML工具，例如我们自己的一个小工具等等。这些工具都是图形画的工具，而现在要推荐的是mscgen：一个用文字描述然后产生MSC图的工具，能生成SVG、PNG等多种格式。
从该工具网站提供的描述看，语法很简单，很有意思，精确地抓住了MSC图的本质，朴实而实用，非常值得大家尝试使用。
Apache自动输入密钥文件密码
从startSSL申请了证书并成功加载到apache，这些都是通用步骤，具体可以直接参考startSSL的说明文档：http://www.startssl.com/?app=21
然而由于密钥文件是采用访问密码保护，因此重启apache时，读取密钥文件会要求手工输入密码，例如以下提示信息：
Some of your private key files are encrypted for security reasons. In order to read them you have to provide the pass phrases. Enter pass phrase:
这样非常不方便，因此需要将密钥的访问密码告诉apache，并自动输入该密码。
以下步骤都是以root身份进行，系统为Debian 7。
创建shell文件：vi /etc/ssl/apache_pass.sh，并输入以下内容，用于输出访问密码：
#!/bin/sh
echo "1234" <-- 这个是密钥文件的访问密码
出于安全的考虑，将这个文件设置为可执行，并且只能由root访问：
chmod 400 apache_pass.sh chmod +x apache_pass.sh
接下来就是修改/etc/apache2/mods-available/ssl.conf文件，将SSLPassPhraseDialog由默认的builtin修改为以下值（其实就是执行上述shell文件）:
SSLPassPhraseDialog exec:/etc/ssl/apache_pass.sh
完成上述步骤后，重启apache2，将自动输入密钥文件的访问密码，不再需要手工操作。
blue moon
字面意思很容易理解：“蓝月亮”，隐含的意思是指“几乎不可能发生的事情”。比如某项已经确定的政策在可预见的时期内几乎不可能更改，就可以用“blue moon”来形容，如下句：
This policy might be updated once in a blue moon.
ALG是什么？
Application Gateway应用服务器的通称，实际上可以按照网络应用分成不同的种类，例如FTP-ALG、HTTP-ALG等。
这里要说说的是SIP-ALG。这个是通信行当的人才明白的东西，估计大多数人基本不关心。而最近不知道刮什么风，越来越多的路由器里居然都内嵌了SIP-ALG。本来这是个很好的事情，毕竟SIP-ALG能让SIP通话更安全、更能帮助私网的SIP电话进行穿越，实在是有诸多的好处。
可是让人奇怪的是，国内很多路由器的SIP-ALG完全起不了作用，反而引入了各种奇怪的问题。不知道是不是某个路由器通用套件内嵌了这个模块，因此大部分路由器厂商不假思索都自动加持SIP-ALG功能。
如果您的VOIP网络遇到了语音问题，如果您花了很多时间都无法解决，不妨查一下路由器的配置，关掉SIP-ALG功能试试。
hg小技巧
比起大名鼎鼎的git，mercurial/hg相对来说默默无闻一些，不过我们一直使用hg，而且感觉还不错，与git相比该有的都有，不该有的都没有。除了clearcase，hg是我非常喜欢的版本管理工具。
hg在branch管理上相比clearcase还是有很大差距，在日常工作中，需要采取一些变通方式。例如以下一些场景：
只显示active的分支
加上参数“-a”即可，完整命令如下：
hg branches -a
如果不想每次都带上参数，默认就只显示active的分支，可以修改hgrc文件，加入以下内容：
[alias] branches = branches -a
关闭分支
实际上我们希望有“删除分支”的功能。在平时工作中，多半有这样的场景：为了查某个问题需要修改代码，为了不影响开发分支或者主线分支，通常都会创建一个临时分支，加入一些打印、调试、定位代码甚至变更处理逻辑等代码。问题定位后，这些代码不需要merge进主线，分支也没有存在意义，最好就删除了事。遗憾的是hg不提供删除分支的功能，因此我们采用“关闭分支”的处理方式：
hg commit --close-branch -m "finish debug, useless now"
并发数
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亿并发呼叫，也就是说只要四套这个系统，就可以让全中国的人同时打电话！
差点被吓死了。
为什么没有选择sipml5
有多种技术和实现方式可以将SIP与webRTC两个世界连接起来，比如我们的miniWebPhone/miniSIPServer以及sipml5等。当然，最早出现的是sipml5以及与TA配套的webrtc网关。既然已经有了sipml5，为什么我们在设计和实现miniWebPhone（以下简称MWP）时，不采用现成的解决方案呢？
回答这个问题之前，请先粗略的看一下完成后的情况。sipml5的javascript文件大小超过2MB，而MWP的javascript文件是20KB。仅仅对比这两个数据，我就认为我们的决定非常正确，sipml5实在是太臃肿了！
造成sipml5如此庞大的根本原因在于：TA的目标是在浏览器端用javascript来实现一个完整的SIP协议栈及呼叫处理过程。理想很丰满，现实太骨感。
我想sipml5的设计者被HTTP与SIP之间的相似性给迷惑了。两者的确都是基于文本格式，SIP甚至都基本遵循HTTP的消息定义，但是两者却有最根本的区别：HTTP本质上是无状态、无层次的协议，而SIP是有严格的状态，不仅有transaction的状态，也有session和dialog状态。同时SIP又是多层次的，包括transaction、session、UA等不同的层次。当你用一个无状态、无差别的协议模式强行去套一个多状态、多层次的模式，工作量无疑是巨大的。
而对javascript语言而言，其实并不擅长去解析或者分析类HTTP协议格式的文本。而SIP协议虽然采用HTTP协议的文本格式，但是在会话过程中，不仅仅要解析到header层面，还要进一步解析内部各种参数。这种情况就更加不是javascript擅长的。因此可以看到sipml5不得不耗费大量的处理过程去解析SIP协议的细节。javascript擅长处理什么文本格式呢？JSON！因此在miniWebPhone的设计和实现过程中，我们理所当然地采用JSON来重新定义消息格式。
让我们再看看服务器端的设计。这又是另一个让人很纠结的地方。由于浏览器不支持开UDP和TCP连接，只支持websocket连接（本质上其实还是个TCP连接），sipml5的设计者们不得不引入SIP over websocket（这个定义到现在还处于draft状态）。而这要求客户端和服务器两端都必须修改才能支持。虽然websocket与TCP几乎没有区别，但是对SIP协议栈、SIP会话层面的处理来说，可不是仅仅重用TCP处理那么简单，服务器端的工作量同样巨大。
说到这里就稍微跑跑题，让我们先吐槽一下浏览器的实现者们。当浏览器支持websocket的时候，实际上就已经支持了TCP，为什么不向应用层开放TCP连接能力？websocket本质上就是个TCP连接，只有开始的两个握手消息是HTTP格式，后续跟HTTP一点关系都没有。同样，既然已经支持了webRTC，为什么不向应用层开放UDP连接能力？打开一个SRTP端口和打开一个UDP端口同样一点区别都没有。如果浏览器开放了TCP和UDP连接能力，哪怕仅仅开放UDP能力，sipml5的开发者也不用一边哭一边改设计，更不用搞出“SIP over websocket”这么个爷爷不疼、姥姥不爱的东西了。
让我们回到原点。分析了这些困难和不足，既然服务器（或者网关）死活都要修改，那我们为什么不把工作量集中到一端，从而解放另外一端？因此我们放弃sipml5，重新思考：
客户端无疑还是必须基于webRTC和javascript的。但是消息格式不再是HTTP或者SIP格式，而是JSON格式，这样javascript就可以轻松处理。客户端采用无状态方式，呼叫的状态由服务器端来维持。这就是MWP的javascript文件仅仅20KB就ok了的根本原因。
既然客户端采用了JSON格式的消息，因此服务器端也要相应作出设计。主要工作无非就是转码成SIP消息格式并维持websocket连接，其他处理仍然可以沿用目前已有的SIP流程。而我们要做的，仅仅是在客户端和SIP之间做个转换层而已。
访问onedrive
一个好端端的网站，被莫名其妙地干掉了。经网友介绍，还好只是DNS污染。网友推荐使用DNSCrypt解决这个污染问题。不过有个更简单点的方法，直接将onedrive的IP地址写入hosts即可。
修改C:\Windows\System32\drivers\etc\hosts文件，增加以下两行记录：
134.170.108.26 onedrive.live.com 134.170.108.152 skyapi.onedrive.live.com
只有在天朝才会明目张胆出现这种不要脸的事吧？
大户型路由器
第一次听到这么个说法，感觉很新奇。于是进一步了解了详情。新闻链接请点击这里。
所谓大户型路由器就是信号超级强，以至于隔着几层楼都能有极好的信号。周老板兴致勃勃地说：在我家三楼别墅都能收到信号哟！
差点笑喷！大哥，路由器信号加强了，笔记本、手机等终端的信号怎么解决啊？路由器怎么收三层楼上各类终端wifi信号啊？难不成将笔记本或者手机也改成大户型笔记本、大户型手机？
不是周老板忽悠大家，就是有钱任性被人给忽悠了。
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日志去追踪相应的代码。