Browsed by
Tag: voip

奇怪的 SIP 呼叫流程

奇怪的 SIP 呼叫流程

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

奇怪的 SIP 呼叫流程
奇怪的 SIP 呼叫流程

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

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

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

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

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

183 带媒体信息
被叫放音,183 消息携带 SDP。

被叫侧如果对接了传统的 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 则直接建立两边的通道,让主叫直接听被叫的放音。

奇怪的需求

奇怪的需求

工作中经常会遇到客户提出各种各样的需求,有些需求很合理,有些需求很有难度,有些需求则让人摸不着头脑,比如今天遇到的一个需求。客户的需求看上去似乎不复杂:

呼叫离线(offline)的被叫用户时,先 push 一个通知(notification)给被叫用户,收到响应后再发起呼叫。

我推测这位客户可能在构建某个移动APP。移动APP经常遇到的问题是:希望常驻后台,但是手机的电源管理往往会优化掉应用。这导致该移动APP会强制退出运行,从而无法正常接收消息、更无法接收呼叫。

客户提出的需求不应该是这个场景的解决方案。应当是APP自身向系统申请足够的权限驻留内存,并且APP应该和 SIP 服务器定时 keep-alive 保持激活状态。前者是APP自身的设计问题,后者是SIP注册、激活问题(标准流程)。

当然这只是我的个人推测,不太适合直接反馈给客户,因此向客户简单地提示了几个问题:

(1)离线状态下,怎么保证收到 notification 呢?

(2)既然可以收到 notification, 为什么就不能收到 SIP 的呼叫消息(INVITE)呢?

2020-10-12 更新: 稍微了解了一下相关的内容,大概是 iOS、Android 提供了统一的通知机制。如果收到了 notifications, 系统会从后台启动程序,这样 SIP 终端又可以重新注册并接收呼叫了。 这种模式当然是可以工作的,不过方案确实也很丑陋。另外,由于 GMS 在大陆已经不可描述了, 因此大陆的 Android 手机就更奇葩一些,通过应用程序链之间互相唤醒、互相调用(脏得一批 ……)。

2020-11-28 更新: RFC8599 定义了 SIP PUSH NOTIFICATION 的规范,对于移动终端 APP 类的 wake up 机制进行了定义。还不清楚该规范的应用情况,待进一步了解。

市场分析后的迷思

市场分析后的迷思

最近不太忙,于是花了点时间研究一下我们云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?

为什么放弃了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的回音消除技术、超强的语音编解码技术等。思虑再三,决定还是不再跟随,砍了算了,以后再说吧。

webRTC调试方法小结

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日志去追踪相应的代码。

VoLTE技术的发展与部署

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将改变运营商和虚拟运营商)。

Voice over LTE

Voice over LTE

从cnBeta网站看到一条信息(http://www.cnbeta.com/articles/116220.htm),大致的意思是:

让HSPA网络也可以承载语音数据,并且还可以在无SIM卡的情况下实现紧急呼叫。这意味着只要有HSPA数据连接,用户就可以直接通过数据网络拨打电话而不是走传统的蜂窝网。新的标准还优化了语音路由,并加入了一系列LTE手机的服务端API。

我比较感兴趣的是:

  • 这个VoLTE和VoIP有什么区别?
  • LTE手机的服务端API是指什么?
  • 是否所有电话都可以通过LTE手机的数据网络完成?