51学通信技术论坛

 找回密码
 立即注册
搜索
查看: 3518|回复: 1

对IMS中SIP用户呼叫E.164号码用户时路由方案的分析与建议 [复制链接]

Rank: 9Rank: 9

发表于 2015-12-15 22:01:29 |显示全部楼层
一键分享 一键分享

文:强 磊(中国电信北京研究院)陈 卉(中国互联网络信息中心)

摘要:目前国内外各通信标准组织都将以3GPP IMS为基础的网络作为未来语音交换网络的演进方向, 由于未来的IMS网络将在很长一段时间内与基于电路交换的电话网络共存, 因此存在着IMS中SIP用户呼叫E.164号码被叫用户时的路由选择判断问题。为此, 本文给出了3GPP IMS中SIP用户呼叫E.164号码被叫用户时在主叫归属S-CSCF可采取的三种路由方案:S-CSCF自身路由方案、ENUM查询判断方案以及BGCF路由判断方案, 并对这三种方案进行了分析比较与应用建议。

1 引言
目前国内外各通信标准组织都将以3GPP IMS(IP multimedia subsystem, IP多媒体子系统)为基础的网络作为未来语音交换网络的演进方向, 包括软交换网络、3G网络、视讯网络等都将逐步朝IMS网络演进。IMS网络的特点是以纯IP网络作为承载网络, 以SIP(会话初始协议)作为基本的通信协议建立会话, 以CSCF(呼叫会话控制功能)实体作为SIP服务器完成终端用户的注册、呼叫的路由和会话的建立。
由于未来的IMS网络将在很长一段时间内与基于电路交换(CS)的电话网络共存(这里的CS既指3G网络中的电路域部分, 也泛指PSTN、GSM等电路交换网络) ,在未来网络中一个采用SIP客户端的IMS终端用户既可能和另一个采用SIP客户端的IMS终端用户通信, 也有可能和一个CS终端用户通信。对于IMS终端用户, 它采用SIP URI(统一资源标识符)来标识自己(称为公共用户身份标识) , 例如一个IMS用户可表示为sip:user1@example.com; 同时也可选择采用原有的E.164号码形式来标识自己, 例如采取网号形式tel:137XXXXXXXX或局号形式tel:+8610XXXXXXXX。而对于一个CS终端用户, 它一般都采取E.164号码来标识自己。

3GPP中规定了如果被叫用户是一个IMS网络的SIP用户时, 即使被叫用户向外公布的是E.164号码, 也要求主叫方在其归属S-CSCF处判断出该被叫用户是一个IMS网络的SIP用户并通过ENUM(telephone number URI mapping, 电话号码到URI映射)查询机制得到该被叫用户的SIP URI地址, 主叫方IMS网络采用该SIP URI进行路由以直接与被叫方IMS网络通信从而建立呼叫。而如果被叫是一个CS用户时, 需要在主叫方S-CSCF(业务呼叫会话控制功能)处判断出该被叫是一个CS用户并将呼叫路由到主叫方网络的BGCF(breakout gateway control function) ,BGCF存储着全网及与其他运营商互通的电路域路由信息, 主叫方BGCF根据被叫所属的电路域网络查询其内部的路由表选择合适的MGCF(媒体网关控制功能)(此时主被叫在同一网络)或被叫方网络的BGCF(此时主被叫在不同网络, 呼叫路由到被叫方网络的BGCF后该BGCF还需选择合适的MGCF)进行路由, 最终由MGCF控制MG(媒体网关)和SG(信令网关)设备将该呼叫路由到电路域。图1描述了上述这两种情况下的简略呼叫流程(详细流程可参见3GPP 24.228) , 图中a情况是指呼叫SIP用户时, b情况是指呼叫CS用户时。图左是运营商C1的IMS网络(IMS-C1) ,图右是运营商C2的IMS网络(IMS-C2)和电路域网络(CS-C2) , 假定主叫用户U1的SIP URI是U1@C1.net, 他属于运营商C1。被叫用户U2对用户U1公布的联络号码是E.164号码:+861058552100,他属于运营商C2; 如果在a情况下U2是SIP用户时, 他除了E.164号码外还有一个没有向U1公布的SIP URI:U2@C2.net。


对a情况(主叫SIP用户呼叫被叫SIP用户)呼叫流程的说明如下:
a1:U1用户呼叫号码为+861058552100的U2用户,U1终端生成的SIPinvite消息经由U1当前所关联的P-CSCF1 (代理CSCF)路由到其归属的S-CSCF1,invite消息中的Request URI是tel:+861058552100。
a2:U1归属的S-CSCF经过分析得知被叫U2用户是一SIP用户, 因此它需要通过ENUM查询机制将U2的tel URL(tel: +861058552100) 翻译成SIPURI(sip:U2@C2.net),S-CSCF1将ENUM查询得到的SIPURI替换掉invite消息中原有的RequestURI,并根据该SIP URI经过DNS查询得知被叫所属网络的I-CSCF(查询CSCF)地址,S-CSCF将呼叫消息路由到I-CSCF2。
a3:I-CSCF2查询HSS(归属用户服务器) 得到当前为用户U2服务的S-CSCF2,I-CSCF2将呼叫消息路由到S-CSCF2,S-CSCF2根据U2注册时所告知的终端联系地址和关联P-CSCF地址将呼叫消息经由P-CSCF2路由到U2。
对b情况(主叫SIP用户呼叫被叫CS用户)呼叫流程的说明如下:
b1:同a1。
b2:U1归属的S-CSCF1经过分析得知被叫U2用户是CS用户, 于是S-CSCF1将呼叫路由到BGCF1。
b3:BGCF1经过对号码的路由分析得知U2属于另一网络C2, 于是选择C2网络中合适的BGCF2将该呼叫路由到BGCF2。BGCF2再经过号码分析选择本网络中合适的MGCF将呼叫路由到该MGCF。MGCF将呼叫路由到电路域, 由电路域的交换机将呼叫路由到被叫终端。
通过以上的分析, 可知在上面两种情况下都需要主叫用户归属的S-CFCF1根据被叫的E.164号码判断被叫号码是SIP用户还是CS用户, 进而采取不同的路由机制和网络进行路由。对于S-CSCF如何根据被叫的E.164号码来判断被叫号码是IMSSIP用户还是CS用户, 目前3GPP并没有给出相应的具体方法, 因而本文针对这一问题提出了以下三种方案并给出了相应的分析和建议。


2 方案描述与分析
下面给出了3GPPIMS中SIP用户呼叫E.164号码的被叫用户时在主叫归属S-CSCF可采取的三种路由方案:S-CSCF自身路由方案、ENUM查询判断方案以及BGCF路由判断方案。
2.1 方案一:S-CSCF自身路由方案
该方案中, 主叫归属S-CSCF根据自身存储的被叫用户网络归属信息可知被叫用户是一个IMS SIP用户还是一个CS用户, 在进行呼叫消息的路由时, 以决定是路由到下跳CSCF设备还是BGCF设备。在这种方案中由于S-CSCF不可能存储太细化的被叫网络归属信息(否则路由表将十分庞大, 而且即使其他运营商仅做号段上小的修改都将会严重地影响该运营商所有S-CSCF中的路由数据, 而S-CSCF作为IMS主要网元,数量众多, 这将造成很大的运维负担和网络的不稳定), 因此可以通过在国际或国家范围内将IMS网络中SIP用户划分成一个新的号段以解决该问题, 例如可以规定SIP用户的号码是:+861060058552100或者是+8660013812345678, 其中600标识了该号码是IMSSIP用户。这样在主叫归属的S-CSCF通过自身存储的信息对被叫号码段进行判断时就可分析出被叫是否是IMSSIP用户, 从而决定是通过ENUM查询得到被叫的SIP URI进而直接将呼叫路由到被叫所属的IMS网络, 还是将呼叫路由到BGCF进而通过CS网络路由。
该方案的最大优点是实现简单, 对呼叫延时小, 便于规划, 部署快。但是其缺点也是显而易见的: 采用号段划分方式使号码长, 不便于记忆; 号码段特殊, 可能会影响用户的使用。由于固定了IMSSIP用户的号码范围, 因而会在网络升级、号码迁移时带来一些问题, 例如: 假如一个不属于IMS SIP号段的原CS用户经过网络升级后升级为IMS用户, 那么若采用该路由方案它就必须改号码或者至少得在号码前增加号段前缀。当然, 也有可采取原号码进行路由的方法, 如先路由到电路域再由电路域路由至IMS网络, 但这样必然会增加路由迂回, 影响了语音质量。


2.2 方案二:ENUM查询判断方案
该方案中主叫归属的S-CSCF假定被叫都是SIP用户, 因此可直接查询ENUM DNS服务器, 根据ENUM DNS服务器的返回结果来判断被叫是一个IMS SIP用户, 还是一个CS用户, 或者有可能就是一个邮件地址,S-CSCF对ENUM DNS查询的结果也有可能为空(即该号码没有在ENUM服务器中注册, 这是可能的, 因为电路域运营商可以不用理会ENUM);S-CSCF根据ENUM服务器的返回结果决定下一步的路由操作, 如果返回的结果是空或者返回的结果中service 字段是: “E2U+voice:tel”( 参见RFC-ietf-enum-voice-01.txt)、Regexp字段中的URL是“tel:”, 那么S-CSCF都将把呼叫消息路由到BGCF, 由BGCF根据其存储的电路域路由信息将呼叫路由到相应的电路域。
该方案的优点是:对S-CSCF的要求低,S-CSCF自身不需要存储路由信息;采用ENUM路由查询, 标准统一, 并且便于路由信息的动态更新和不同运营商网络的互通, 例如:某运营商某号码的路由信息发生变化(如从CS用户变为IMS用户), 不需要通知其他运营商, 只需要将该号码新的路由信息以NAPTR(naming authority pointer) 记录的形式提交给该号码所属的ENUM注册机构即可。该方案的主要缺点是:ENUM体系还不十分成熟, 并且ENUM查询有一定延时, 因此在被叫是电路域用户、查询结果是空或tel URL的情况下, 查询没有获得任何具体的路由信息, 还需将呼叫路由到BGCF, 严重增加了呼叫建立的延时和造成了资源的浪费。


2.3 方案三:BGCF路由判断方案
上述两种方案的思想都是与3GPP一致的, 另外作者还提出了一种新的方案:BGCF路由判断方案, 与3GPP存在着一些不一致之处。在BGCF路由判断方案中,S-CSCF假定地址是tel URL的用户都是CS用户, 因此对于invite消息中Request URL字段是tel URL的呼叫消息都路由到其关联的BGCF设备(如果是SIP URI字段仍然按照原有机制进行呼叫路由),BGCF接收到invite消息提取出Request URL字段的tel URL值后首先根据其内部的路由表分析tel URL中的E.164号码是否在路由表中存在映射关系, 如果有则按照路由表中相应的路由信息进行路由; 如果没有映射关系, 则BGCF将查询ENUM DNS服务器获得该E.164号码所对应的SI PURI (这点与3GPP规定不同,3GPP中对ENUM DNS服务器的查询都是在S-CSCF中完成),BGCF得到ENUM查询结果后可以有两种方法进行下一步的路由, 一种方法是BGCF将ENUM查询结果返回给主叫归属S-CSCF, 由S-CSCF进行SIP呼叫消息的路由(见图2情况a);
另一种是BGCF直接根据ENUM查询结果将SIP呼叫消息路由到IMS中的其他网元, 例如另一运营商的I-CSCF(见图2情况b)。这两种方法都是3GPP在对BGCF的功能要求中所没有规定的, 方法1利用SIP的重定向机制, BGCF负担小(无须代理路由非CS域的呼叫路由信息), 但是多了两次BGCF与S-CSCF之间的往返过程, 增加了迂回(BGCF不参加后续SIP方法消息的路由); 而方法2利用了SIP的代理机制, 较方法1少了一次从BGCF到S-CSCF的返回过程, 但是BGCF由于要承当一部分到IMS域SIP消息的路由(当IMS SIP被叫用户只向外公布E.164号码时), 因此对BGCF的要求较高, BGCF负担较重; 具体采用哪种方法可根据设备商所提供的BGCF能力及运营商的偏好和实际情况确定。上述两种方法的简要呼叫流程见图2, 图中终端U2是一个IMSSIP用户, 但向外公布的是E.164号码。


对图2中a情况的呼叫流程说明如下:
a1:U1用户呼叫号码为+861058552100的U2用户,U1终端生成的SIPinvite消息经由U1当前所关联的P-CSCF1路由到其归属的S-CSCF1,invite消息中的RequestURI是tel:+861058552100。
a2:S-CSCF1分析invite消息中的Request URI是tel URL,于是将呼叫路由到其关联的BGCF1。
a3:BGCF1首先在自己的路由表中查找+861058552100的映射关系, 由于没有相应的映射BGCF1再查询ENUM DNS服务器以获得该E.164号码对应的SIP URI。
a4:BGCF1向S-CSCF返回重定向“301 Moved Permannently”消息, 该响应消息中的Contact字段包含了被叫的SIP URL。
a5:S-CSCF根据“301消息”中Contact 字段的SIP URL通过DNS查询将呼叫路由到被叫归属网络的I-CSCF。
a6:I-CSCF2 查询HSS得到当前为用户U2 服务的S-CSCF2, 将呼叫消息路由到S-CSCF2,S-CSCF2根据U2注册时所告知的终端联系地址和关联P-CSCF地址将呼叫消息经由P-CSCF2路由到U2。
对b情况的呼叫流程说明如下:
b1~b3:同a1~a3。
b4:BGCF根据ENUM查询得到的SIPURI, 再通过DNS查询得到被叫的SIPURI, 直接将呼叫路由到被叫归属网络的I-CSCF。
b5:同a6。


3 方案比较与应用建议
当IMS中SIP用户呼叫E.164号码被叫用户时, 上述三种方案都可以用来在主叫侧进行路由判断。三种方案中方案一最简单, 易于实现, 但是固定了号码段, 不利于网络的升级和号码的迁移, 而这是CS网络向IMS网络的演进过程中所不能避免的。方案二由主叫归属的S-CSCF借助标准的ENUM机制进行路由判断, 具有较好的通用性, 但在呼叫电路域用户时存在着ENUM查询的延时, 因此在ENUM查询尚不成熟时(例如查询响应慢)不适合采用。方案三由BGCF首先进行内部路由判断,在内部判断没有匹配时再进行ENUM判断, 避免了方案二的ENUM查询延时, 但增加了S-CSCF与BGCF之间的消息传递延时, 不过该时间与ENUM查询时间相比是可以忽略的(目前ENUM远程查询时间平均达到400~600ms); 但是该方案存在着与3GPP的不一致之处, 需要IMS网络运营商自己对设备提供商提出功能要求, 或者3GPP组织采纳该方法并对目前的规范进行相应修改。
综上所述, 当IMS中SIP用户呼叫E.164号码的被叫用户时, 在ENUM系统尚未引入或引入的初期可采用方案一;ENUM系统成熟后、响应时间达到要求后可采用方案二; 对于方案三,运营商可根据自身实际情况自行采用, 也可在3GPP通过该方案后再考虑采用。
[作者简介] 强磊, 中国电信北京研究院工程师, 主要研究方向为软交换和IMS网络技术; 陈卉, 中国互联网络信息中心工程师, 主要研究方向为ENUM及域名寻址技术。


附件: 你需要登录才可以下载或查看附件。没有帐号?立即注册
51学通信(www.51xuetongxin.com):致力打造最好的通信技术在线学习平台 。

Rank: 2Rank: 2

发表于 2015-12-17 15:25:02 |显示全部楼层
感谢分享

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

站长邮箱|Archiver|51学通信 ( 粤ICP备11025688 )

GMT+8, 2024-3-30 00:00 , Processed in 0.049433 second(s), 15 queries .

Powered by Discuz! X2

© 2001-2011 Comsenz Inc.

回顶部