Pi打开IPv6
默认已经安装了IPv6协议栈，但是没有打开IPv6功能，这点比较奇怪。不过打开IPv6功能也不复杂，一行命令即可：
sudo modprobe ipv6
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 更新：好吧，我承认我还是图样了。
为什么放弃了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的回音消除技术、超强的语音编解码技术等。思虑再三，决定还是不再跟随，砍了算了，以后再说吧。
实现一个简单的SMTP发送库
最近在优化“语音邮箱”业务时，发现采用python-smtplib库虽然能满足需要，但是还是有很多不足，因此决定自己重新写一个库，当然仅仅实现发送email（包含附件）即可。实现一个完整的SMTP服务可能比较复杂，而实现一个单纯的、高性能的SMTP客户端发送库却比较容易。
与SIP、HTTP等协议类似，SMTP也采用文本方式定义消息格式，而附件等二进制内容，则采用base64转码成文本，这样就极为方便开发和调试。以下是SMTP最基础的几个RFC文档：
RFC5321： SMTP
RFC5322： Internet message format
RFC4954： SMTP Service Extension for Authentication
RFC3207： SMTP Service Extension for Secure SMTP over Transport Layer Security
RFC2035： Multipurpose Internet Mail Extensions
我们结合SMTP的流程，来简要说明SMTP协议中的各个关键点。
一、标准端口
SMTP基于TCP连接，SMTP服务器默认打开的端口是25、587或者465。通常是采用25端口，后期设计加密SMTP（即SMTPS）时采用了465端口。而IANA在新业务端口规划时占用了465端口，因此将587端口定义为TLS加密的SMTP端口。
目前各email服务商通常都会同时打开25和587端口，有些为了和以前老客户端程序兼容，也会打开465端口。
这里面其实可能存在一个误解，似乎25端口就是不加密的SMTP，而587、465就是加密的SMTP。实际上不是这样，现代SMTP服务器一般都已经支持STARTTLS（即RFC3207），因此在25端口也可以启动SSL/TLS加密，这取决于客户端是否具备SSL/TLS加密、解密能力，这点在后续流程中会详细描述。
二、基础流程
2.1 建立与SMTP服务器的连接
建立TCP连接，连接到服务器的25端口或者587端口。如果是25端口，则是建立普通TCP连接即可。如果是587端口，通常可以直接建立SSL/TLS连接。需要注意的是，有些SMTP服务器的587端口也是要求普通TCP连接，后续STARTTLS流程中再启动SSL/TLS加密。这种情况下，587端口的流程与25端口的流程一致。
我们的示例流程中，采用QQMail的SMTP服务器做参考，因此我们首先向“smtp.qq.com”服务器的25端口建立连接。连接成功后，服务器应返回220消息，告诉客户端连接成功：
220 smtp.qq.com Esmtp QQ Mail Server
2.2 初次握手
SMTP客户端发送EHLO命令给服务器，进行初次握手协商：
EHLO 192.168.1.101
“EHLO”实际是ESMTP（Extended SMTP）的指令，意思是要进行用户名和密码的鉴权。远古时代的SMTP不需要鉴权的情况下，可以直接发送HELO命令进行握手。目前的SMTP服务器基本都是支持ESMTP，因此如果不刻意区分的话，后续的SMTP实际就是指ESMTP。
SMTP服务器器收到上述消息后，返回本服务器的一些能力信息给客户端：
250-smtp.qq.com
250-PIPELINING
250-SIZE 73400320
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN
250-MAILCOMPRESS
250 8BITMIME
其中最关键的就是STARTTLS能力，也就是该SMTP服务器具备加密连接能力。通常都建议采用加密连接以确保数据安全，毕竟互联网上总有一些黑暗势力在窥探您的信息。
如果客户端不具备SSL/TLS能力，则直接跳到“账户鉴权”流程即可。此时就不能采用PLAIN鉴权模式，必须采用MD5等加密鉴权模式。
2.3 加密连接
既然服务器明确了SSL/TLS能力，因此客户端只要启动SSL/TLS加密TCP连接即可。客户端发送STARTTLS命令，通知服务器准备加密：
STARTTLS
服务器返回响应消息，通知客户端可以开始加密：
220 Ready to start TLS
接下来就是在TCP连接上建立SSL/TLS加密连接，后续通信以后都基于SSL/TLS连接。
请注意，QQMail服务器目前似乎只支持SSLv2、SSLv3加密，不支持TLSv1.0，TLSv1.1和TLSv1.2加密，其他的SMTP服务器（例如outlook、gmail等）则支持全部加密方式。
2.4 第二次握手
加密连接建立后，再次发送EHLO命令进行握手：
EHLO 192.168.1.101
同样，服务器返回相应能力进行响应。此时，通常不再包含STARTTLS指令了：
250-smtp.qq.com 250-PIPELINING 250-SIZE 73400320 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN 250-MAILCOMPRESS 250 8BITMIME
2.5 账户鉴权
鉴权有多种方式，其中PLAIN方式是要求所有SMTP服务器都必须具备的。在未加密的情况下，采用PLAIN方式无疑会泄露账户密码信息。而在已经加密的SSL/TLS连接里，则不存在这个问题，因此我们采用了最简单的PLAIN方式传递账户密码信息进行鉴权。
PLAIN方式很简单，采用”\0user name\0password”进行编码，然后base64转化成文本格式即可。
客户端发送以下鉴权命令：
AUTH PLAIN my_demo_base64_string_here
服务器鉴权成功，返回响应消息：
235 Authentication successful
2.6 提交邮件地址信息
鉴权成功后，客户端可以开始告诉服务器邮件地址信息，例如发送者、接收者等。此类消息不一一累述，请直接参考以下消息流：
MAIL From:<Iloveu@foxmail.com>
250 Ok
RCPT To:<Iloveu2@msn.com>
250 Ok
2.7 准备递交邮件内容
客户端发送DATA命令，告诉服务器准备提交内容：
DATA
服务器返回响应消息，通知客户端可以开始发送数据：
354 End data with <CR><LF>.<CR><LF>
由于后续数据都采用文本编码，因此标准规定用“\r\n.\r\n”标识数据发送结束，也就是SMTP服务器在上述响应消息中指示的“<CR><LF>.<CR><LF>”。
2.8 发送邮件内容
邮件采用文本格式，附件采用base64编码，可以分多次发送，以下为一个简单示例：
From: <Ilovu@foxmail.com> To: <Iloveu2@msn.com> Subject: You have a new voice mail: From 301 Day 2015-12-14 Time 10.29.7 MIME-Version: 1.0 Content-type: multipart/mixed; boundary="==491D4D07305F440E009A0125==" --==491D4D07305F440E009A0125== Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="From 301 Day 2015-12-14 Time 10.29.7.wav" UklGRpKaAABXQVZFZm10IBIAAAAGAAEAQB8AAEAfA...... --==491D4D07305F440E009A0125==-- .
对于有附件的情况，应在Content-Type中指明boundary参数，例如本例中的“==491D4D07305F440E009A0125==”。而附件内容起始处用“–boundary参数”标识，附件结尾用“–boundary参数–”标识。
发送完数据后，服务器响应消息：
250 Ok: queued as
2.9 结束
发送完邮件后，客户端友好地向服务器告别：
QUIT
服务器也友好地告别：
221 Bye
最后关闭TCP连接，完成整个流程。
掉坑里了
Qt无疑是个非常好的framework，我们一直用TA。虽然不敢说已经是行家里手，不过好歹也开发这么久程序了，渐渐地有些自负起来，因此掉坑里了。
坑来自Qt最经典的设计：signal-slot。我以前的理解这是异步的，常用于模块间解耦。在windows平台，这个理解似乎没错，signal-slot底层依赖window的message机制。而在linux平台，其实现方式默认仍然是callback机制。
callback机制在多线程编程里最容易出问题的就是“锁”。这次掉坑里，就是在slot中应用“锁”时不小心，导致了死锁。
这次竟然忘了这点！ :-(
virtualbox无法启动虚拟机
前几天系统升级到win10，初步体验了一下，感觉不如win7，不过已经升了，也就算了。但是比较闹心的是，virtualbox无法启动虚拟机了！vbox中共创建了两个虚拟机，分别是Debian7（32bit）和Debian7（64bit），都无法启动，一启动就报错：VERR_VM_DRIVER_VERSION_MISMATCH。
在网上查了很久，并重新装了vbox的4.x版本和最新的5.x版本，问题始终存在，一度误解为win10的问题。今天无意中发现vbox安装目录下有driver目录，考虑到出错提示的信息隐约和驱动有关，因此试试安装了其中的驱动，问题居然就好了! 安装文件为以下文件（视vbox具体安装目录而异），右键点击文件，然后点击“安装”即可：
D:\Program Files\Oracle\VirtualBox\drivers\vboxdrv\VBoxDrv.inf
回顾问题，究其原因可能在于win10是升级，而不是全新安装，因此残留了vbox以前的一些配置，而这些信息在两个系统中又是不一致的。vbox自身也有问题，删除旧版本时显然没删干净，至少旧的驱动程序保留下来了。
推荐一个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功能试试。