采用SIP-INFO消息来传递DTMF信号，似乎只是Cisco的定义，没有一个成文的标准，但是目前主流的SIP厂家基本都遵循了相同定义，主要采用‘Signal’参数传递DTMF值：
Signal=1
Duration=160
其中，Signal与DTMF信号对应如下：
DTMF Signal ------------------------- 0--9 0--9 * 10 # 11 A--D 12--15 Flash 16
这种映射关系与RFC2833规范一致。但实际上，SIP-INFO既然是文本消息，其实没必要进行转译。例如，传递‘*’信号时，目前的处理是：
Signal=10
Duration=160
这样的定义非常不直观，完全可以直接传递，如下：
Signal=*
Duration=160
SIP-INFO这样传递显得非常直观。RFC2833二进制协议，只能进行定义转换，但是SIP本身是文本协议，足以进行文本性描述。可惜当初不知道为什么非要按照2833方式进行定义，也许这就是为什么这种方式始终没有成为正式规范的原因。
时间过得真快！从U公司离职，仿佛还是昨天发生的事情。
两年过去了，回头看看，自己真是在一个不太好的时间点选择了创业，非常鲁莽。这两年无论生活还是工作，都发生了巨大的变化，这些变化造成的压力有时候显得实在过于沉重。
希望接下来的日子会好一些。
传统电信网的各项规范往往经过了很多专家的讨论以及厂家的验证，因此显得比较严格和规范，例如传统的ISDN规范，定义都很明确。
而因特网的各项规范对比之下就显得很随意，往往是一个规范出来之前就考虑不周全，然后根据情况，又补充出一堆的规范。即使这样，仍然是显得有很多漏洞，或者说有很多不规范、不明确的地方，导致各厂家各说各的道理，给互联互通造成很大的困扰。
当然不是说传统电信规范没有漏洞或者定义含糊的地方，只是相比之下，因特网的规范实在是过于随意。
比如说SIP呼叫中的主叫号码。
在电信网规范中，与主叫相关的号码定义非常明确，主要就这么几个：主叫号码、原主叫号码以及显示号码。各号码的应用场景也非常明确，号码格式中的显示属性等也很明确。
在SIP规范中，与主叫相关的头域有这么几个：From, Contact, P-Asserted-Identity, P-Preferred-Identity, Remote-Party-ID等。这些定义要么没有明确规范好，要么就是多次一举，多半是RFC定义者遇到情况时，拍脑袋一想：算了，加个新的定义搞定吧。结果就让人很无语了。
From和Contact在标准的SIP code规范RFC3261中有明确定义，通常我们都认为From域中携带主叫号码，可惜规范并没有明确限定，因此有一些厂家往往在Contact域中携带主叫号码，而在From域中只携带地址信息。
而显然在实际应用中又遇到一些主叫号码显示的场景（估计主要是电信专家考虑3GPP网络的各项应用时，遇到了与传统主叫号码类业务的冲突），于是乎RFC3325规范就粉墨登场，一举增加了P-Asserted/Preferred-Identity两个头域，也是用来携带主叫号码信息。其中，P-Asserted-Identity主要在信任域的server之间、proxy之间、server与Proxy之间进行传递，而P-Preferred-Identity主要在UA与server/proxy之间传递。看，无聊不？折腾不？
而在正统的P-xxx-Identity头域出来前，民间的野路子显然也遇到了同样的主叫号码类业务的问题，于是乎定义了Remote-Party-ID，并基本参照了ISDN的一些定义，例如号码是否显示等属性，很多SIP厂商已经很high地支持了这个定义，比如说Asterisk。发现没？有了这个定义，还要P-xxx-Identity等定义干什么呢？但是不幸的是P-xxx-Identity已经是正式RFC规范，而Remote-Party-ID还停留在draft-xxx-04阶段（目前已经超时，不知道还会不会升级到正式RFC规范），因此SIP厂商不得不同时支持上述各个定义了。
我有没有提到：有些SIP设备在From/Contact等常见域中根本不携带号码，只在www/proxy-authorization中携带鉴权用户的号码，往往也就是作为主叫号码？
晕倒吧！
由于工作上的需要，最近两天折腾openssl来实现一些信令加密解密的事情。总体来说，openssl是个很不错的库，也是个很不错的工具。使用openssl做tls客户端编程没有太大问题，而实现tls服务器端则有些地方需要注意。
首先要注意的一点就是：在握手之前（SSL_accept），绝对不能采用非阻塞方式。握手成功之后，才可以将socket修改为非阻塞方式，否则握手不会成功，服务器总是会向客户端返回“Engypted alert”消息并结束握手。
如果是在windows环境生成证书和密钥，建议使用SimpleCA工具，很好用。同时要注意：（1）客户端应安装或者使用该工具生成的根证书，例如ca.crt。（2）服务端需要使用生成的服务端证书和密钥，即.crt和.key文件。（3）生成证书时（无论是根证书还是服务端证书），Common Name都必须要设置为当前服务器的IP地址或者主机名，否则双方握手时，可能产生”certificate name mismatch”等错误。（4）如果需要将证书导入windows系统，必须导入为“受信任的根证书颁发机构”类型。
如果是Ubuntu等linux系统，可以直接安装使用openssl生成证书，如以下命令：
生成根证书： openssl genrsa -out ca.key 4096 openssl req -new -x509 -days 3650 -key ca.key -out ca.crt 生成服务端证书和密钥 openssl genrsa -out server.key 1024 openssl req -new -key server.key -out server.csr openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
理论上来说，可以将.crt和.key文件合并在一起，设置为.pem文件。不过实践证明，openssl的API是要求SSL_CTX_use_PrivateKey_file函数来加载密钥文件的，否则握手还是会出问题（当然，也可能是需要另外单独的设置）。
由于ｌｉｎｏｄｅ默认的内核（ubuntu10.04）缺省将ＳＩＰ等协议过滤模块编入了内核，而且linode默认没有采用模块化的方式，因此被迫重新编译内核。linode提供了一篇文档指导如何使用自编译的内核，但是在细节上实际还是有不同，导致按照文档的步骤编译后，系统没办法启动。于此记录一下，以备后续需要。
采用linode的文档编译和配置，往往会出现以下一些错误：
i8042 no controller found
udevd[1077]: failed to create queue file: no such file or directory udevadm[1816]: error sending message: connection refused.
第一个错误涉及menu.lst，在这个文件中，不能像文档那样，启动时携带’quiet’参数。
第二个错误与Ubuntu版本可能有关，需要人工指定/dev，需要修改/etc/fstab的配置（后续说明细节）。
基本步骤如下：
下载最新的kernel代码并解压：
wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.7.6.tar.bz2
将系统原有的config导入到kernel源代码的目录下，同时根据自己的需要修改.config文档：
zcat /proc/config.gz > .config
顺序执行以下命令：
make oldconfig
make -j3 bzImage
make -j3 modules
make
make install
make modules_install
如果成功，应该在/boot目录下看到新生成的内核文件，例如vmlinuz-3.7.6等。
创建/boot/grub/menu.lst文件，添加以下内容：
default 0
timeout 5
title Custom Compiled, kernel 3.7.6
root (hd0)
kernel /boot/vmlinuz-3.7.6 root=/dev/xvda ro
注意，Ubuntu版本可能还需要安装grub软件：
apt-get install grub
修改/etc/fstab目录，添加以下内容：
dev /dev devtmpfs 0 0
完成上述步骤后，修改linode中该node的profile，将kernel修改为pv-grub-x86_32，然后重启启动该node即可完成升级。SSH登录系统，使用uname -a命令即可查看新内核版本。
2013-07-19 update:
在编译3.9.x内核时，出现以下错误信息：
/bin/sh: bc not found
此时，安装bc即可：
apt-get install bc
问题基本情况如下：我们开发并发布了一个软终端产品，当然其中采用QT以及Phonon模块。在我们的开发环境中，一切都很美好，能正常地播放音乐。可是安装到客户的计算机上，出现问题了，无法播放提示语音（wav文件录制）。
这个问题的实质是我们没有将Phonon的插件一同打包进安装文件。Phonon实质上只是个前端封装模块，具体工作有赖于后台的解码器。在windows系统中，Phonon缺省采用DirectX作为后台解码器部分，具体实现为一个plugin。如果不安装这个plugin，则phonon无法正常播放语音文件。
假设QT安装在d:\qt\4.8.4目录下，则上述plugin可以在以下目录中找到：D:\Qt\4.8.4\plugins\phonon_backend\phonon_ds94.dll。
注意，不是简单地将这个文件拷贝到程序目录下即可，而是要拷贝到程序目录的phonon_backend子目录下。例如，我们的程序安装在d:\minisipphone目录，则上述dll应当拷贝为：d:\minisipphone\phonon_backend\phonon_ds94.dll。
另外需要注意的是，不同版本的QT要采用各自版本的phonon_ds94.dll，例如qt 4.6.2的程序就不能采用qt 4.8.4的phonon_ds94.dll，否则还是会出现放音错误。
国外的产品还是比较有良心, 看看下面这个厂商, 提供的独立服务器产品性价比很高:
http://www.ubiquityservers.com/
希望将来产品做大做强后, 能逐步迁移到这样强大的平台上去.
这是一篇访谈记录的翻译稿，主题是讨论VoLTE技术。被访问者是BroadSoft公司的CTO。这篇文章能帮助我们初步了解VoLTE的一些概念。原文在此，译文如下。
GSMA在2010年移动世界年会上宣布, 将支持VoLTE技术作为LTE语音方面的技术选择.
然而,只有在首先部署LTE网络的情况下, 才会选择VoLTE. 因此, 我们请教Scott Hoffpauir(Broadsoft公司CTO), 他是如何看到VoLTE的发展与部署情况.
关于VoLTE究竟是什么,目前没有太多的信息. 这也是我们首先想了解的问题之一.
Q: Scott, 您能帮助我们区分基于3G的VoIP, 基于WiFI的VoIP以及VoLTE这些技术之间的差异吗? 是否可以说VoLTE是4G时代的VoIP?
当我提到VoLTE时, 我是指GSM组织的IR.92技术规范. 这些规范重点定义: 在采用IP多媒体子系统(通常也被称为IMS)的LTE网络, 如何部署语音和短信业务. 换句话说, VoLTE本质上就是基于4G IMS网络的VoIP技术.
IR.92规范同时也定义了基于WiFi如何部署语音和其他业务. 实际上, 部分移动运营商也计划使用WiFI辅助LTE. 既然IMS可以作为LTE和WiFi的通用核心网, 因此这两种技术提供的业务实际上是一样的.
Q: 移动运营商采用VoLTE能获得什么好处呢?
LTE网络在世界范围内的广泛部署, 不仅仅是提供难以置信的速度和数据吞吐量, 满足迫切需要更多带宽的移动消费者和数据应用程序. 它同时也为移动网络运营商提供新的功能和通信工具, 同时进入到普通消费者市场和企业市场.
催化剂就是LTE中采用的IMS网络, 它能帮助移动运营商继续提供高速数据业务, 改进的语音业务, 同时将新的创新业务, 增强的统一通信概念(例如状态呈现, 即时通信, 视频以及数据共享等), 集成进单一的接入点, 即移动电话.
世界上没有DSL接入(译注: 大概是指没有宽带接入的)的大部分国家将能采用LTE技术接入internet. 这不仅能帮助移动运营商拓展他们的市场, 也意味着我们将看到大量的商业机会将出现在大城市之外, 并创造新的就业机会, 带来新的投资.
运营商们需要将他们与顶级运营商(OTT)区分出来. 他们的优势在于, 基于他们的网络, 他们能够控制业务的质量, 并且能够部署高品质的业务. (译注: 没搞懂这是什么意思?)
Q: 我们能期待VoLTE达到运营商级的要求吗?
VoLTE技术规范确保(VoLTE)最低限度的语音质量和业务要求应当和当前的电路交换语音一样好, 甚至更好. 运营商可以调节VoIP和视频的流量以保护他们的网络资源. 在欧洲, 部分运营商已经这么做了. (译注: 语音质量有保证, 而且可管可控)
Q: 部署VoLTE有时间表吗? 您预计什么时候会有大规模的市场应用?
我们预计最初会在2012年部署VoLTE.早期部署有可能会采用VoLTE增强3G基本语音呼叫的呼叫体验, 例如高清语音或者视频. Verizon(VoLTE领域的领导者)计划在2012年进行商业部署, 升级他们全国的业务. 根据AT&T的报告, AT&T计划在一年后,也就是2013年,开始商务部署VoLTE.
大规模部署VoLTE可能会遇到“鸡与蛋”的情况。也就是说，只有在市场上已经有足够数量和品种的LTE手机时，运营商才会大规模部署LTE网络。 然而，我们怀疑手机制造商会等到LTE网络大规模部署并且达到人们的期望值时，才开始为大批量生产LTE手机进行投资。
今年的四，五月期间，我们和一个专家调查组合作，调查了全球范围内一些领先的移动运营商，咨询了一系列关于VoIP策略， 统一通信，丰富通信套件（译注：什么东东？）以及LTE等问题。
我们调查的这些运营商中，没有一个认为LTE手机会在今年内获得广泛的应用。实际上， 大约34%的运营商认为2013年之前LTE都不会是一个可行的消费产品， 32%的运营商则认为是2012年之前。 另外18%的运营商认为可能要到2014年， 10.5%的运营商认为是2015年。还有5%的运营商认为可能是2016-2020年，那时才可能有足够的设备（LTE手机）。
然而， Verizon在这方面敢于挑战，他们现在已经向客户销售一些LTE手机， 其中包括三种智能手机，分别由HTC，三星以及LG提供生产。
我们讨论越多的VoLTE话题，关于LTE部署方面的问题就越来越明显。运营商需要很明确地知道什么是VoLTE以及该技术的优点。
我们需要理解VoLTE技术，以确保在应用它的过程中获得它所有的优势优点。GSMA已经将其作为技术标准，所有的运营商都将应用它。
其他解决方案目前看都不会成为标准，所有的运营商都需要采用一个通用的标准。（译注：意思是LTE就是这个通用标准）。
Q：与其他方案（例如VoIP）相比， 采用VoLTE有什么优势吗？
采用IP和LTE语音有诸多优势。VoIP已经显著地改进了现代通信业务，而VoLTE将这种进化推进到下一个阶段。OTT语音业务将与VoLTE进行竞争。然而，考虑到（VoLTE）运营商对网络有全面的控制，他们的业务比OTT语音业务有非常强的竞争力，就像今天的3G语音业务一样。（译注：说得很空洞，很外交词令啊。。）
Q：部署VoLTE时，运营商需要了解些什么？
我们讨论LTE时，我想非常重要的一点就是运营商并没有将其视为3G网络的进化。而认为它是新的IP接入技术。很多人将LTE看作是DSL的替代技术。很多地区的消费者无法采用DSL技术，而现在他们可以接入到LTE网络中（译注：没有条件部署固网宽带，现在可以用无线宽带了，至少省掉了挖坑埋线等费用）。所以，VoLTE也能帮助移动运营商（MNOs）拓展他们的市场。
然而，移动运营商们将面对新的挑战。目前他们的主要收入来自于传统的语音业务，这部分业务的总通话时间正在逐月下滑。更重要的是，随着LTE技术的引入，如果这些运营商不能提供增值业务，那么OTT运营商将提供（新的增值业务）。
因此移动运营商需要确保他们传统的收入来源保持增长，同时又要提供新的业务。仅仅是替换语音业务是不够的，他们需要提供更多的东西。
Q：谁将首先部署LTE？相关测试已经开始了吗？
LTE后的推动力是非常巨大的。移动运营商们没有太多的选择，只能逐步进化他们的网络，跟上蓬勃发展的高速数据应用的需求。正如我前面说的，如果这些运营商不能支持高速数据业务，并且无法提供增值业务， OTT运营商将会提供。现实情况就是数据类业务正日益成为网络流量最大的来源。
Verizon在7-28日宣布它将在28个城市中部署LTE网络，覆盖超过100个地区。TeliaSonera在北欧和波罗地海地区部署业务后， 也正在将LTE网络拓展到拉脱维亚。
另外20多个国家的54家运营商正在进行LTE技术的试验或者测试，加上已经正式承诺部署商业网络的运营商，现在有80个国家大约208家运营商正在对LTE进行投资。
根据BroadSoft的LTE调查报告，大约四分之三的被调查运营商声称他们将在最近部署一个LTE网络，其中42%已经部署或者试商用了LTE。
因此我们一点都不惊讶GSMA声称LTE是发展最快的移动技术。
Q：VoLTE最大的机遇是在商业领域还是消费领域？
最初会在消费领域。根据我们的调查， 45%的运营商认为他们不会准备提供LTE作为企业解决方案。然而，63%（的运营商）指出他们已经为他们的企业客户提供了统一通信服务，大多数是围绕着黑莓提供的服务（译注： 大概out了）。
另外，66%的运营商认为VoIP以及统一通信对于企业产品是‘非常重要’甚至是“极端重要”的。对比45%的运营商认为不准备向企业用户提供LTE，这显得非常有趣。根据这些数据，我们可以合理假设: 商业服务在VoLTE（4G)与3G的竞争中将有更大的作用。
Q：基于LTE的UC（统一通信）将具有哪些显著的提高？
主要的提高就是个人将在任何时间， 任何地点，通过各种各样的设备（包括智能电话和平板电脑）保持连接。
在LTE网络中，是否会出现更多的MVNO（译注：移动虚拟运营）机会？ 运营商们是否会将其看作是产生批发收入的冒险者？
鉴于LTE为移动运营商提供了新的一系列业务机会（超出传统的语音、短信以及数据业务），LTE为运营商带来的各种可能性相当令人兴奋。您可以设想全国以及全球的零售商带给市场大量的设备，能够与基于云的业务交互，例如视频通话，流媒体等。
毫无疑问，LTE将成为游戏的改变者，无论运营商拥有当前网络还是利用一个代理网络。（译注：LTE将改变运营商和虚拟运营商）。
在SIP族协议中，只有RFC4028明确讨论了对话keep-alive问题。实际上这在工程应用、生产环境部署中，是个非常重要的话题，尤其是SIP基于UDP协议时，网络原因丢包是很常见的，另外还有软终端任意退出对话等情况。缺乏keep-alive保护的SIP服务器毫无疑问将会严重消耗资源，最终导致整个server被迫退出服务。
RFC4028协议考虑到有状态Proxy、无状态Proxy等情况，提出扩展Session-Expires以及Min-SE两个新的Header，并且通过reINVITE消息来keep-alive dialog。基本上，这个协议本身没有太多问题，按照它的思路，的确是可以解决keep-alive的问题，但是在实际部署中，该协议未必可取，有很大的缺陷：
（1）SIP运营商可能会拒绝reINVITE消息。实际上很多SIP运营商会拒绝reINVITE消息，这是出于SIP运营商媒体处理方面的考虑。最初应用reINVITE就是为了修改媒体流，而这毫无疑问会导致SIP运营商媒体服务器重新分配资源等情况出现。RFC4028中只是定义了新增Header和callFlow，不幸的是，却没有区分出这个reINVITE与更改媒体流的reINVITE，因此实际部署时是否有效，我们需要打一个很大的问号。
（2）采用reINVITE流程太过重型了。正如前面所说，keep-alive的reINVITE消息是没有与更改媒体流的reINVITE进行区分，因此可以肯定绝大部分SIP服务器或者终端，在收到这个reINVITE消息时，会启动媒体更改流程。对话内重改媒体毫无疑问是个很重型的流程，一旦对话内本身就可能有媒体类业务，例如Music On Hold等，就很有可能导致冲突。
如果不采用reINVITE消息，在4028协议中也同时建议可以采用UPDATE消息。在UPDATE消息中可以不携带SDP更改媒体。这种方式可能是比较可行，但是未必所有的SIP设备会支持UPDATE消息并用于keep-alive过程。
方案之二应该采用SIP最基础协议RFC3261中定义的OPTIONS消息。理由如下：
（1）该消息定义在RFC3261协议中，这个协议是整个SIP协议族的基础。基本上不可能有SIP设备（包括服务器、Proxy、终端等）会不支持这个消息。
（2）我们注意到，这个消息可以在对话内，也可以在对话外使用。在RFC3261中很明确地定义了：
An OPTIONS request received within a dialog generates a 200 (OK) response
that is identical to one constructed outside a dialog and does not
have any impact on the dialog.
（3）对话内使用OPTIONS，最显著的优点就是“does not have any impact on the dialog”，对现有对话没有任何影响，更不可能去更改媒体。
（4）对端设备如果由于某种原因已经退出，当然就不能产生200OK响应消息，此时可以理所当然地拆除当前对话，从而保护服务器自身资源，达到keep-alive的目的。
对于设备层级的keep-alive，采用OPTIONS没有任何问题。但是对于dialog层级的keep-alive，则会有问题。原因在于：dialog内的OPTIONS消息有可能被对端作为对话外的OPTIONS来处理。也就是说，如果设备是alive的，但是dialog的BYE消息丢失了，无论dialog内还是dialog外，设备对OPTIONS都可能会返回200OK。
Requests that do not change in any way the state of a dialog may be received within a dialog (for example, an OPTIONS request). They are processed as if they had been received outside the dialog.
方案三是采用RFC5626协议，对于UDP-SIP的情况，该协议建议采用STUN keep-alive方式。缺陷在于：定义有些复杂，而且很多SIP设备未必会支持。
呼叫服务器和媒体服务器合一的情况下，当然也可以由媒体服务器检测RTP/RTCP来keep-alive，不过这是另外一个topic了，这种方式可能更合适于SIP终端设备。
过去一直在尝试使用Amazon的EC2云计算环境，并曾经逐步将工作中大量相关资源转移到该系统中。
应该说EC2给我留下了非常深刻的印象，然而结果却并不美好，有各方面的原因，最终导致我放弃了EC2。
最根本的原因是目前从国内访问EC2实在是太慢了。回想起去年我刚接触EC2时，非常惊讶于EC2的速度，无论是虚拟机的运行速度还是网速，都非常让人满意，当时的上传速度轻松就能达到近百KB/s，为此我甚至将VPN环境也转移到了EC2，实在是太方便了。而现在，常常出现连接超时、龟速等让人难以忍受的情况。这个问题不能全部归结于Amazon本身，也与我们猥琐的墙有关（具体原因大家都懂的）。
而最近Amazon本身似乎也有问题。在重新创建instance时，居然只有us-east四个区可选择（？现在的情况是否有改善不得而知）。而恰恰是这四个区今年以来问题不断，要么是连接性问题，要么是API问题，几乎每月都会有。当然这些问题不一定会影响到最终的接入速度或运行状态，但是毫无疑问让人感觉很担忧，尤其是将企业业务运行在这种环境时就显得更严重了。
从一些Amazon的一些新闻判断，Amazon可能将大量EC2或者S3的资源调度给自身的云应用了，例如Amazon视频、Kindle fire等，而留给外部客户的资源自然就少而且差了，这可能也是为什么只有us-east四个区可选择的原因之一。Amazon很有可能不会平等对待外部客户，而以内部应用优先。这对Amazon来说理所当然，但对外部客户而言就需要重新考虑了。
鉴于以上各种因素，最终我们转向了独立VPS提供商。虽然费用比EC2贵些，但是目前至少还没有受到太多的鸟气，感觉比较满意。
最后，再一次Fuck那个众所周知的墙以及它的设计者、制造者和维护者。