sip – 静水潜流

奇怪的 SIP 呼叫流程

2022/04/26 YI

最近几天帮助泰国的朋友检查一个呼叫业务流程，其中涉及很多细节和业务流程，不过让我觉得特别意外的是他使用的 VoIP 运营商的 SIP 呼叫流程。首次遇到这样的流程，请先参考下图的概要描述：

这个流程的奇怪之处在于：（1）VoIP 运营商发起呼叫时，INVITE 消息的媒体地址居然是“0.0.0.0”，这很明确告诉被叫：主叫只发送媒体流、甚至根本不处理媒体流；（2）被叫应答后，VoIP 运营商再次发起 reINVITE 流程，此时才真正指示出自己的真实媒体地址（当然也包括最终的媒体编码）。

通常的 SIP 呼叫流程在发起呼叫时就明确指示自己的真实媒体信息，因此在被叫应答后，没有必要再发起 reINVITE 流程。然而这家运营商为什么要放弃传统做法、采用这么奇怪的流程呢？

这家运营商是美国的一家运营商，而且规模很大，其设备供应商也是一家世界级的大软件公司（非常、非常大），因此这个流程肯定不是随意修改的结果，必定有其特殊的目的。仔细揣摩后，我认为它可能是为了节省媒体资源才这么做。

被叫方一般会振铃几秒、十几秒、甚至几十秒后，才可能应答。另外，呼叫量特别大时，统计上只有10%左右的呼叫最终才会应答。这家运营商采用这个流程，只需要在被叫真正应答之后才开始分配媒体资源，考虑到这是一家规模很大的运营商，这种流程确实可以节省很多的媒体资源。

VoIP 网络往往是主叫播放回铃音，因此这是个非常聪明、折中的呼叫流程，确实只有在被叫侧应答之后才处理真实媒体流。然而现实网络组网是非常复杂的，这个聪明到有些投机取巧的方法有固有的缺陷，请参考下图：

被叫侧如果对接了传统的 PSTN 网络，例如 VoIP 网关，很有可能直接返回 183 消息并携带被叫的媒体信息。传统的 PSTN 网络往往是被叫侧播放回铃音，并且也有一些被叫侧放音的业务（例如“彩铃”），此时这家 VoIP 运营商就有问题了。

由于它告诉给被叫的地址是“0.0.0.0”，因此被叫振铃音（或者业务音）就无法传达到主叫侧。VoIP 运营商可以向被叫发送 UPDATE 消息来传递自己的真实媒体信息，但被叫未必会支持 UPDATE 消息，这个是扩展消息，不是所有的 SIP 设备都必须支持。而且 PSTN 网络往往会要求对 18x 消息用 PRACK 流程确认，因此即便支持 UPDATE 消息，这个特殊流程实际也急剧放大了被叫侧振铃阶段流程的复杂度。

这也就是我们的泰国朋友遇到的问题。

解决方式是在 VoIP 运营商与 PSTN 网络之间架设 miniSIPServer：

（1）miniSIPServer 与 VoIP 之间建立完全应答的呼叫通道；

（2）miniSIPServer 与 PSTN 之间维持正常的呼叫流程；

（3）miniSIPServer 判断被叫侧是否自己放回铃音（或者业务音），如果（a）被叫没有放音，则 miniSIPServer 主动给 VoIP 运营商放回铃音（或者呼叫等待音），而如果（b）被叫有放音，miniSIPServer 则直接建立两边的通道，让主叫直接听被叫的放音。

RFC4235与RFC7463

2018/11/22 YI

基本上两篇RFC文档是传承的关系，RFC7463场景应用比RFC4235要详细很多，一些旧的SIP设备未必支持7463。

在兼容性方面，对于SIP-SUBSCRIBE消息，两篇RFC文档采用了不同的Event，rfc4235中定义“dialog”，而rfc7463中定义“dialog;shared”。rfc4235限定在只订阅SIP呼叫对话的状态，因此在dialog-info中，要求必须填充dialog元素，其中就包含call-id，remote-tag以及local-tag等典型呼叫参数。

而rfc7463不仅仅是关注呼叫，更关注“状态呈现”，因此凡是与“状态”相关的消息，都尽量进行了定义。比如在“11.1. Registration and Subscription”章节中，就定义了终端注册的状态呈现。在注册流程中，就没有dialog的信息。

呈现信息多，对用户当然有好处，对VoIP系统也很有意义，尤其是在企业应用场景中。但是需要注意的是这也大大增加了VoIP系统的负荷，实际部署中要慎重考虑。

市场分析后的迷思

2016/03/22 YI

最近不太忙，于是花了点时间研究一下我们云SIP服务的市场情况。结果很出乎意料，很多结论与我们的预想是完全相反。

做云SIP服务的初衷是来自一些客户的反馈：MSS最小版本都支持20部SIP分机，而有一部分用户的场景中没有这么多分机，因此购买一套MSS软件稍显浪费。另外，有一些区域的用户，比如中国大陆，认为软件贵了点，希望能更便宜一些。

因此我们做了云产品，预计大部分用户会创建少量的资源（分机、外线等），同时也希望能吸引一些不太愿意为软件进行投资的用户。

经过基本的数据分析，我们得出以下一些结论：

1、不愿购买软件的人更加不会购买服务

云SIP服务不仅仅是产品，本质上更是服务，我们维护着整个VoIP网络系统的稳定，检查各种失败呼叫的情况，为客户排忧解难等等，这些都是对用户非常有价值。而数据表明，云SIP服务的客户范围与本地MSS软件的销售范围是高度重合的，仍然是以欧美客户为主，我们期待的拓展客户并没有出现。

不认可软件价值的人，也很难去认可服务的价值。

2、欧美客户更愿意购买服务

我们原先预想：部分对价格比较敏感的用户会使用我们的云SIP服务，另外用户熟悉过我们的云产品后，感觉满意的话，可能更愿意在本地部署自己的VoIP网络。而实际情况是：

（1）对价格敏感的客户更愿意选择本地SIP服务器版本。这部分客户通常是非欧美客户。

（2）我们的很多客户是已经购买了MSS软件，尝试了云SIP服务后，反而将本地VoIP网络迁移到云服务上。这部分用户更看重稳定的网络和专业的服务质量。当然也有部分用户与我们的预期是一致的，最终购买了软件。这部分客户通常来自欧美地区。

3、价格不是关键因素

云SIP服务虽然每资源定价很低，但是如果设置大量资源的话，总体成本会逐渐超过MSS软件的成本，因此我们预期用户不会添加太多的资源，这样也与MSS软件形成互补。然而让我们惊讶的是：大量客户设置的资源数（分机、外线、语音文件等）居然超过20！跟踪分析了其中一部分长期用户的数据，结果发现这部分用户支付的费用足够买好几套软件了。

显然，对这些高价值用户而言，价格肯定不是关键因素，至少不是决定性因素。专业化的服务、稳定的网络、简单易用的使用体验才是吸引他们的关键。因此我们进行设计时，无需过多考虑价格，而更应该关注产品本身。

4、个性化需求还有待挖掘

首先说一下结论：我们极少遇到个性化需求。少数几个提出个性化需求的客户最终也没有成为我们的长期客户。

云SIP服务一个让我们自鸣得意的特性就是对IVR-XML以及Python脚本业务的支持。这个特性非常有利于我们为客户提供或者适配个性化的通信业务。我们甚至预期大量的客户会提出此类需求，比如不同的IVR流程等。然而现实就是“并没有”，大家都还是在使用默认的各种业务和呼叫流程，这有点让人郁闷，感觉辛苦努力的东西其实是屠龙之技。

这点结论可能值得商榷，还需要继续观察。至少我个人仍然认为多数企业对自己的通信需求都会有个性化的地方，目前这个结论可能是我们没有真正了解到客户的需求造成的，也可能是我们的客户群还不够广泛造成。

为什么放弃了webRTC？

2016/02/22 YI

首先必须要说明的是：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的回音消除技术、超强的语音编解码技术等。思虑再三，决定还是不再跟随，砍了算了，以后再说吧。

“r”与”rb”

2016/01/12 YI

最近做一个测试，模拟收发和解析一些SIP消息。方式方法很简单：将消息存在一个文本文件（.txt）中，读取该文件，然后解析、发送等操作即可。

因为是文本文件，因此想当然地就调用fopen函数”r”模式读取好了：

fopen("d:/demo.txt", "r");

然而让人惊讶的是：读取的结果和实际消息居然有差异，直接导致消息解析失败。百思不解之下不得不进行调试，结果发现丢掉了所有的’\r’符号。

从问题的现象看，感觉是windows平台的C库在读取文本文件时，擅自判断了CRLF（’\r\n’），并错误认为CR符号多余，从而跳过了所有该符号。这个处理只是猜测，对一般的文本处理当然没有问题。而对绝大部分基于文本的互联网协议而言，例如SIP、HTTP、EMAIL等，CRLF有非常重要意义，丢失CR符号无疑会产生非常严重的问题。

解决方法也很简单，就是不再当成文本文件读取，而采用二进制文件读取模式，无差别读取所有内容即可：

fopen("d:/demo.txt", "rb");

补充：在Debian中做了同样的测试。结果表明：linux系统的C库以’r’方式打开文本文件时，不会自作主张地将CR符号去掉，与预期结果一致。

ALG是什么？

2015/05/02 YI

Application Gateway应用服务器的通称，实际上可以按照网络应用分成不同的种类，例如FTP-ALG、HTTP-ALG等。

这里要说说的是SIP-ALG。这个是通信行当的人才明白的东西，估计大多数人基本不关心。而最近不知道刮什么风，越来越多的路由器里居然都内嵌了SIP-ALG。本来这是个很好的事情，毕竟SIP-ALG能让SIP通话更安全、更能帮助私网的SIP电话进行穿越，实在是有诸多的好处。

可是让人奇怪的是，国内很多路由器的SIP-ALG完全起不了作用，反而引入了各种奇怪的问题。不知道是不是某个路由器通用套件内嵌了这个模块，因此大部分路由器厂商不假思索都自动加持SIP-ALG功能。

如果您的VOIP网络遇到了语音问题，如果您花了很多时间都无法解决，不妨查一下路由器的配置，关掉SIP-ALG功能试试。

为什么没有选择sipml5

2015/01/23 YI

有多种技术和实现方式可以将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之间做个转换层而已。

webRTC调试方法小结

2014/11/25 YI

前段时间完成了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信号的若干约定

2013/04/22 YI

采用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呼叫中的主叫号码

2013/04/15 YI

传统电信网的各项规范往往经过了很多专家的讨论以及厂家的验证，因此显得比较严格和规范，例如传统的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中携带鉴权用户的号码，往往也就是作为主叫号码？

晕倒吧！

静水潜流

记录一点生活

Browsed by
Tag: sip