推荐一个MSC小工具：mscgen
在通信设计中经常需要使用消息序列图（MSC），目前市面上有很多画MSC图的工具，例如UML工具，例如我们自己的一个小工具等等。这些工具都是图形画的工具，而现在要推荐的是mscgen：一个用文字描述然后产生MSC图的工具，能生成SVG、PNG等多种格式。
从该工具网站提供的描述看，语法很简单，很有意思，精确地抓住了MSC图的本质，朴实而实用，非常值得大家尝试使用。
ALG是什么？
Application Gateway应用服务器的通称，实际上可以按照网络应用分成不同的种类，例如FTP-ALG、HTTP-ALG等。
这里要说说的是SIP-ALG。这个是通信行当的人才明白的东西，估计大多数人基本不关心。而最近不知道刮什么风，越来越多的路由器里居然都内嵌了SIP-ALG。本来这是个很好的事情，毕竟SIP-ALG能让SIP通话更安全、更能帮助私网的SIP电话进行穿越，实在是有诸多的好处。
可是让人奇怪的是，国内很多路由器的SIP-ALG完全起不了作用，反而引入了各种奇怪的问题。不知道是不是某个路由器通用套件内嵌了这个模块，因此大部分路由器厂商不假思索都自动加持SIP-ALG功能。
如果您的VOIP网络遇到了语音问题，如果您花了很多时间都无法解决，不妨查一下路由器的配置，关掉SIP-ALG功能试试。
并发数
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之间做个转换层而已。
大户型路由器
第一次听到这么个说法，感觉很新奇。于是进一步了解了详情。新闻链接请点击这里。
所谓大户型路由器就是信号超级强，以至于隔着几层楼都能有极好的信号。周老板兴致勃勃地说：在我家三楼别墅都能收到信号哟！
差点笑喷！大哥，路由器信号加强了，笔记本、手机等终端的信号怎么解决啊？路由器怎么收三层楼上各类终端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日志去追踪相应的代码。
SIP-INFO传递DTMF信号的若干约定
采用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方式进行定义，也许这就是为什么这种方式始终没有成为正式规范的原因。
SIP呼叫中的主叫号码
传统电信网的各项规范往往经过了很多专家的讨论以及厂家的验证，因此显得比较严格和规范，例如传统的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技术的发展与部署
这是一篇访谈记录的翻译稿，主题是讨论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通信网中极有可能实现.