Browsed by
Category: 通信技术

通信,让生活更美好!

SIP呼叫中的主叫号码

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技术的发展与部署

这是一篇访谈记录的翻译稿,主题是讨论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通信网中极有可能实现.

基于HTML5的SIP客户端

基于HTML5的SIP客户端

项目名称是:sipml5,地址:http://code.google.com/p/sipml5/

该项目基于Google的WebRTC项目。这点与我以前写的一篇blog吻合,将SIP引入WebRTC不仅是可能,而且已经有人搞定了!

粗略地看了一下该项目的情况,界面是比较丑陋,不过看介绍应该是基本可用的。这是个好消息啊,尤其对企业用户而言,可能都不需要每个员工安装部署SIP终端,直接部署该终端即可,再结合云通信平台,整个系统都能简化不少。

如果该项目能覆盖Chrome, Firefox以及IE三个主要平台,基本就可以在实际环境中部署。非常让人期待啊。

在Ubuntu/Kubuntu中以非root用户身份运行wireshark

在Ubuntu/Kubuntu中以非root用户身份运行wireshark

缺省情况下,只允许以root身份运行wireshark,否则无法抓包,命令如下:

sudo wireshark

每次都这样启动实在是比较麻烦,最好还是允许普通用户也运行wireshark并抓包。为此,需要执行以下命令即可:

sudo dpkg-reconfigure wireshark-common
sudo chmod o+x /usr/bin/dumpcap
RFC4028的不足与SIP keep-alive方法

RFC4028的不足与SIP keep-alive方法

在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与SIP

WebRTC与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

RTMP

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进行转换和互通。这是个很不错的想法,让人有很多想象空间。

iLBC相关说明

iLBC相关说明

在两篇RFC文档中对iLBC有比较全面的介绍:

1、RFC3591 Internet Low Bit Rate Codec (iLBC) 这篇主要是讲解iLBC的基本原理,非语音处理领域的专业人士很难看得明白。

2、RFC3952 Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech 进行RTP传输是必须遵守的规范,VOIP领域人士基本能看明白。

简单点说:iLBC采用8KHZ,16bit采样,但是分成两种模式:30ms(毫秒)模式以及20ms(毫秒)模式。最初只定义了30ms模式,后来考虑到窄带网络丢包的情况,增加了20ms模式。目前大部分设备多采用的是30ms模式。

30ms模式是指每30ms发送一帧,则每帧数据是400bits (50bytes),如果是20ms一帧,则每帧数据是304bits(38bytes)。

在SDP描述中,必须明确指明codec名字是iLBC。

如果是20ms模式,必须在SDP中明确指明,否则会认为是30ms模式。在RFC文档中有如下描述:

If 20 ms frame size mode is used, remote iLBC encoder SHALL receive “mode” parameter in the SDP “a=fmtp” attribute by copying them directly from the MIME media type string as a semicolon separated with parameter=value, where parameter is “mode”, and values can be 0 and 20 (where 0 is reserved and 20 stands for preferred 20 ms frame size).  An example of the media representation in SDP for describing iLBC when 20 ms frame size mode is used might be:

m=audio 49120 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20 <– 30ms模式中,多数厂家的设备不会携带这个attribute。

需要注意的是SDP协商与一般的codec协商有不同,其中比较关键的就是ptime不能应用到iLBC的协商中。iLBC总是采用最低速率模式,例如,只要一方要求30ms模式,双方都必须使用30ms模式:

That is, an offer of “mode=20” receiving an answer of “mode=30” will result in “mode=30” being used by both participants.  Similarly, an offer of “mode=30” and an answer of “mode=20” will result in “mode=30” being used by both participants.

注解:我想可能就是这个原因(当然,也有历史遗留的可能),大家都不约而同地采用30ms模式,避免对媒体资源的重新调配。

不能使用ptime的原因在于一个RTP包中,可能会封装若干个iLBC包,这种情况下ptime无法表述究竟是哪种模式:

Parameter ptime can not be used for the purpose of specifying iLBC operating mode, due to fact that for the certain values it will be impossible to distinguish which mode is about to be used (e.g., when ptime=60, it would be impossible to distinguish if packet is carrying 2 frames of 30 ms or 3 frames of 20 ms, etc.).

注解:在一个RTP包中封装多个iLBC包的方法,实在让人感觉多此一举。即没有减少流量,也不能降低丢包对语音质量的影响,反而增加了网络设备的复杂性。从实际应用来看,也没有什么人会采用这种方式。