通信，让生活更美好！
采用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方式进行定义，也许这就是为什么这种方式始终没有成为正式规范的原因。
传统电信网的各项规范往往经过了很多专家的讨论以及厂家的验证，因此显得比较严格和规范，例如传统的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中携带鉴权用户的号码，往往也就是作为主叫号码？
晕倒吧！
这是一篇访谈记录的翻译稿，主题是讨论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将改变运营商和虚拟运营商）。
自从苹果重新崛起后, “软件+硬件”的产品形态引起了大家的关注. 以往要么关注硬件, 要么关注软件. 而一体化设计带来的革命性体验, 重新引发了再思考: 专注在硬件, 或者专注在软件还是未来的趋势么?
其实不仅是苹果在终端层面带来一体化体验, 在核心网络层面, IBM也实际上走软硬一体的路子, 包括现在的Oracle也在进行这方面的尝试.
由此我们对通信领域进行再思考: 通信设备提供商和通信业务服务商(运营商)在未来有没有可能融合呢? 早期的AT&T毫无疑问是这种模式的实践者, 并达到了让人惊恐的量级. 而目前随着云计算\云技术的发展, 基于这些技术提供分布式虚拟通信设备, 并提供个性化通信服务似乎不在是梦想.
自己构造通信基础设施, 直接面对终端用户, 直接迭代式开发, 快速满足用户的个性化需求, 带给用户全新的通信体验, 这似乎不能依赖各自分离的通信设备商或者通信运营商来完成了. 传统的通信生态圈在很大程度上是由硬件的复杂性决定的, 各种各样的硬件设备\通信协议\电气协议\网络等级等因素造成了整个网络的复杂性, 封闭性. 而IP技术不断渗透到通信领域, 实际上在不断降低通信的门槛, 并将整个通信网扁平化, 开放化.
可以设想, 如果将来的通信网全部IP化后会怎样? 首先就是目前的那些专有硬件设备大部分都不再需要了, 通信网将是一个扁平的平等网络, 原有的基础通信概念都将被颠覆. 现有的通信设备和运行模式无法满足更有弹性, 更大容量, 更个性化的通信需求.
而融合产品设计实现与业务运营的模式, 可能是未来的趋势. 这种模式在传统的PSTN通信网络体系中是不可能出现的, 而在未来的全IP通信网中极有可能实现.
项目名称是：sipml5，地址：http://code.google.com/p/sipml5/
该项目基于Google的WebRTC项目。这点与我以前写的一篇blog吻合，将SIP引入WebRTC不仅是可能，而且已经有人搞定了！
粗略地看了一下该项目的情况，界面是比较丑陋，不过看介绍应该是基本可用的。这是个好消息啊，尤其对企业用户而言，可能都不需要每个员工安装部署SIP终端，直接部署该终端即可，再结合云通信平台，整个系统都能简化不少。
如果该项目能覆盖Chrome, Firefox以及IE三个主要平台，基本就可以在实际环境中部署。非常让人期待啊。
目前发现比较好的SIP终端软件有以下两个，
CSipSimple : http://code.google.com/p/csipsimple/
SipDroid : http://sipdroid.org/
CSipSimple的口碑似乎还不错。看了一下它的网站，CSipSimple采用了pjsip协议栈，这个协议栈终端设备中有广泛的应用。
2013-09-13 updated：根据最新消息，下个版本的Asterisk很有可能选择pjsip作为新的sip协议栈。
缺省情况下，只允许以root身份运行wireshark，否则无法抓包，命令如下：
sudo wireshark
每次都这样启动实在是比较麻烦，最好还是允许普通用户也运行wireshark并抓包。为此，需要执行以下命令即可：
sudo dpkg-reconfigure wireshark-common
sudo chmod o+x /usr/bin/dumpcap
在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终端设备。
毫无疑问，WebRTC是个好东西。之所以这么说，是因为他居然开源了GIPS的audio引擎。GIPS的回声抑制、噪声消除等方面的技术，几乎独步天下。当年GIPS仅靠这些个算法包，就活得有滋有味。Skype、MSN、QQ等等，凡是做IP语音通信的，都无一例外地使用了GIPS的技术，这里还没包括各硬件芯片厂商。
Google居然将它开源了，牛啊！实在是让人佩服！
既然已经开源了，我们也希望在已有的free项目中引入webrtc的相关模块（主要是EC, NS等）。看了一下webrtc的文档（目前还是非常简陋），忽然有个想法，其实我们没有必要将webrtc的模块引入我们的项目，相反，我们只需要基于webrtc，将我们已经实现的SIP会话层以及GUI层添加到webrtc中。从webrtc的模块分层看，这样似乎更可行一些。
替换掉webrtc的会话层，或者新增SIP会话层似乎都是可行的。不过编译webrtc实在是麻烦，居然要vc2005（还不能是express版本）/ Win7 SDK / DirectX SDK等等，个个都是巨无霸。
另外，这个对Speex项目应该也有影响吧？Speex项目自己实现了一个audio引擎，不过其中的EC，NS等关键部件效果还是不太让人满意，不知道他们会不会从webrtc中获得灵感。
RTMP全称是Real Time Messaging Protocol。这个协议由Macromedia公司开发，为Flash player以及Flash media server提供语音、视频流媒体服务的私有协议。目前Macromedia已经公开了这个协议的细节。
值得注意的是，虽然Flash player/media server/RTMP通常用于提供网络视频流媒体，例如各种各样的视频网站，它们的组合也可以提供在线会议的功能。考虑到几乎所有的浏览器都可能安装有flash，因此终端用户几乎不需要另外安装软件，就可以访问视频、会议等服务，对这些业务的在线部署实在是非常方便。
Macromedia公开RTMP协议，可能是出于与HTML5竞争的需要。这对最终用户而言，无疑是有利的。
而吸引我注意的则是另外一则消息：FreeSwitch最新版本中实现了mod_rtmp模块，通过这个模块，FreeSwitch可以成为RTMP Server，并与传统的SIP进行转换和互通。这是个很不错的想法，让人有很多想象空间。