SBC对IMS网络会议URI影响研究

摘  要：为了解决在IMS网络中引入SBC所带来的会议URI传递不正确的问题，本文分析了SBC的工作机制，3GPP IMS会议规范和RFC 3261定义的URI传递方式，提出了五种可能的解决方案，并分析各种方案的优缺点，确定了一种比较合理的解决方案。

1.    引言
    IMS是3GPP定义的一种网络架构，叠加在分组域网络之上，可以通过IP网络向用户提供多种业务。通过IMS系统，可以向3G用户提供基本语音业务、补充业务、PoC、Presence、即时消息、多媒体会议、智能业务以及其他业务。IMS网络可以通过ISC接口，向业务层开放网络的控制能力，支持第三方的业务开发。IMS网络和接入技术无关的网络，不论用户通过GPRS网络、WCDMA网络、固定IP网络，都可以使用同样的业务。

    在3GPP R5中，明确规定应用多媒体域业务时，用户终端必须使用IPv6地址进行通讯。IMS系统中的所有功能实体，包括用户终端UE、呼叫状态控制服务器CSCF（包括P-CSCF、I-CSCF、S-CSCF）、媒体网关控制服务器MGCF、媒体资源MRFP和应用服务器AS都必须支持IPv6，GGSN与IMS接口也必须支持IPv6，为支持动态地址解析，GGSN还需支持IPv6的DHCP。

    2003年，移动运营商为给3G用户提供更丰富的多媒体业务，促进WCDMA IMS及早引入，向3GPP提出建议，重新审视IMS使用IPv6的决定是否符合整个业界的潮流，是否满足运营商和厂家的共同利益。由于IPv6规模商用达不到原来预计的速度，缺乏所有基于IPv6产品的支持将使基于IPv6的IMS应用延迟[1]。

    为了适应IMS网络商业在目前IPV4网络上商业化的需要求， 3GPP从R6开始，支持终端、网络设备使用IPV4协议。目前，在中国，以及世界各地已经有不少IMS试验网，这些网络绝大多数都基于IPV4网络。中国移动在IMS方面也做了许多详细的工作，基于IPV4,在山西省建设了CM-IMS(China Mobile IMS) 试验网。在试验网建设过程中发现目前3GPP定义的会议标识，和SBC(Session Boarder Controller) 的行为存在冲突，导致在业务使用过程中，终端行为不一致。在下文中，我们将分析3GPP定义的会议标识传递机制和SBC行为之间的矛盾，并提出解决方案。

2.    SBC对IMS会议URI的影响2.1.     IMS网络支持固定接入和SBC
    IMS网络最初的目标是为UMTS/WCDMA的无线接入方式，提供一个可控制的，有QoS保证机制，支持ISC接口，并且兼容现有的CAMEL和Parlay API 接口的多媒体业务支持平台。从3GPP  IMS的框架体系结构上看，虽然最初只针对SGSN/GGSN方式的接入，但是它对上层应用的支持具有良好的通用性，基于SIP协议实现会话控制，和具体的IP技术接入手段无关，采用统一用户管理、鉴权认证、QoS控制和计费机制，能够满足固定/移动融合的基本要求。因此，IMS网络被认为是固定网络和移动网络融合的一种理想方案，得到了移动运营商的广泛支持。

    虽然IMS具有和接入无关的特性，能够支持固定网络和移动网络的融合，但是在实际网络部署中还是存在许多问题。 例如，3GPP IMS网络架构中，终端通过SGSN，GGSN接入到IMS网络中，网络认为接入网络是可信的，安全程度高，地址空间也是由运营商自己控制和规划的，不存在地址空间的重叠的问题。如果固定IP网络中的终端接入到IMS网络，情况就完全不同了，接入的IP网络是不可信任的网络，甚至存在欺诈和遭受攻击的可能。 固定IP网络的应用场景非常复杂，企业、家庭可以根据自己的需要布置相应的子网，可以使用私有的地址空间，并可以配置私有的DNS服务器。如果允许固定IP网络中的终端直接接入到IMS网中，那么P-CSCF将暴露给用户，给网络的安全带来了隐患。 因此，在支持固定网络IP接入场景中，引入（SBC）Session Border  Controller。引入SBC之后的IMS网络如图1所示。

图1：支持固定IP接入的IMS网络

    SBC的功能在3GPP的规范中并没有详细的定义，但SBC所完成的许多功能是运营商构建安全、可控的IMS网络所必需的。SBC主要完成拓扑隐藏、媒体流整形、能力失配修正、NAT穿越、接入控制、协议修正、媒体加密等功能[2]。在图1中，IP网络中的用户可以通过SBC接入到IMS网络，SBC能够把SIP消息中的IMS网络内部地址转换为SBC地址，替换Contac头、删除Via、Record-Rout头；同时，把UE侧的地址转换为SBC的地址，使得IMS看到的IP地址都是SBC的地址。SBC的这种工作方式可以防止外部网络的对IMS网络设备的DoS攻击，但SBC这种隐藏网络内部拓扑的行为导致了原3GPP中的定义的会议业务和SBC不能兼容。

2.2.     IMS网络会议URI传递方式和SBC行为的冲突
    在3GPP的24.147 “Conference Using IP Multimedia Core Network(CN) Subsystem”标准中定义了,会议创建方式以及会议的处理流程，在附录的A.3中规范给出的不同场景之下创建会议的流程。在5.3.1.3.2中，规范中明确说明，当会议的参加方需要创建一个会议时，会议参加方根据TS 24.229生成Invite请求消息，把会议工厂的URI作为Invite请求的URI，向会议工厂发出Invite请求。 会议参加方收到200 OK响应后，如果Contact 头中包含“isfocus”属性，那么，会议参加方应该存储Contact中的内容，作为所创建会议的URI[3]。

    3GPP定义的这种会议创建方式，在端到端的网络中能够工作的很好，能够正确的传递会议URI，保证业务能够正常运行。但在IMS网络中引入SBC之后，SBC要作网络的拓扑的隐藏，会把Contact中的内容替换为SBC为自己的私有标识。这样当会议URI传递到终端会议参与方之后，会议参与方从Contact中得到URI并不是网络中创建的会议URI。Confer URI的处理情况如图2所示。

图2： 引入SBC后的URI传递示意图

       在中国移动山西试验网中，我们采用Ethereal软件，对进出SBC的200 OK消息抓包，抓包的结果如图3所示，图中的网络设备由阿尔卡特提供，终端由华为公司提供。

图3：SBC两侧200 OK中的Contact消息参数变化

       由于SBC是在会话控制路径中插入的一个设备，为了实现网络的拓扑的隐藏，以及内网、外网地址的转换，它修改了网络中会议服务器返回给终端Contact中的URI，这样导致在终端UA收到的Contact中的URI和服务器发出的不一致。 如果这时候，UA采用Out of Dialog的方式请求加入新创建的会议，那么由于这个会话对SBC来说是一个新的会话，SBC不会对经过转换的URI做任何修改，这样URI对于SBC背后的网络来说是不可识别的。这样用户发出的会议请求消息会失败，导致会议不能正常建立。在中国移动CM-IMS山西试验网中，SBC厂家根据发现的这种情况，修改了SBC的映射规则，能够在后续的Dialog中，把经过转换的信息URI再映射为网络中初始分配的URI上。上述的这种方式虽然能够保证会议业务能够正常建立起来，但是，由于终端侧看到的会议URI是经过SBC修改的，终端需要把此URI作为会议名称显示给用户，如果用户处于不同的SBC之下，那么在同一个会议中的用户看到的URI将不相同，这将影响到业务的用户体验。

3.    会议URI解决方案3.1.       SBC的行为分析
    在第二章中，我们分析了引入SBC之后，会议业务中，SBC修改Contact中的URI导致的会议建立不正常的问题。这主要是由于SBC为了隐藏核心网络的地址信息而导致的。 根据IETF Draft的定义，SBC完成拓扑隐藏，NAT、媒体整形、参数匹配、接入控制等功能。为了实现ＳＢＣ两侧地址空间的独立，SBC对SBC地址空间和IMS网络地址空间中的IP地址做双向的影射，把IMS网络侧地址信息影射为SBC地址空间侧的地址之后，发送给UE，把UE的请求消息中的地址影射为IMS网络中的地址之后，送到IMS网络， 如果From, To中包含IP地址，IP地址也会被转为SBC自己的IP地址。

    SBC的这种隔离地址空间的功能对于在目前网络中开展IMS业务是非常重要的，它可以把IMS网络中的IP地址和接入网的IP地址完全隔离开来， 允许在不引入IP V6的情况下，大规模的部署IMS网络，便于IMS的推广。 采用SBC之后的IMS网络地址空间结构如图４所示。

图4：引入SBC后的IMS网络地址空间示意图

    从图4中可以看出，SBC试图把整个网络划分为多个地址空间，IMS网络、接入网的各个地址空间互不干扰。 IMS网络中各种网元、服务器、业务平台都是位于一个独立的地址空间内。从IMS网络看， IMS网络包括自己内部的网元，以及网络边缘的SBC。从终端侧看，终端只能看到网络终端SBC，IMS网络位于SBC的保护之后。IMS终端和IMS网络中业务平台位于一个虚拟的地址空间中，这个地址空间称为IMS业务URI空间，包括用户URI、业务URI，这个空间是全局有效的，SBC对这些URI不做转换。

    在会议业务中，会议工厂临时为会议分配了URI，SBC认为所有会话控制过程中的地址都是网络内部的信息，不允许终端看到这些信息， 因此，把此信息做了翻译。SBC的这种处理方式和会议的业务逻辑相矛盾，导致会议工厂创建的URI不能达到UA。

       我们认为SBC的这种分割地址空间的能力对于IMS网络的部署和运营来说是有益的，由于IP V4的地址空间有限，在中国这样的大国运营IMS必然面临IP V4地址不够的问题。 如果采用SBC之后，可以把IMS网络分为多个地址空间，每一个地址空间中可以使用全部的地址，这样可以有效地解决地址空间的问题。引入SBC后对会议业务的影响可以通过完善3GPP IMS规范、IETF RFC来解决。

3.2.        解决方案分析
    针对上文中提出的问题， 从网络运营，支持合法的侦听的角度看，在IP网络中部署SBC是非常有必要的。在保留SBC分割地址空间的功能之下，可以采用以下几种方式解决IMS网络中会议URI的传递问题。

     P-AI方案：在会议中，网络通过P-Asserted Identify来传递所创建的会议的URI

      Display Name方案：使用Contact传递URI，SBC保证能够把终端URI映射回网络侧分配的URI，业务标准规定在Contact中增加Display Name，用于在终端上显示会议名称

     上下文判断方案：SBC分析信令中的业务参数，在会议中，Contact中的URI后有“isfocus”属性，根据“isfocus”判定这是一个会议URI，不做转换

     SIP头扩展方案：在SIP协议中扩展Global-Contact消息头，这个头中的内容是一个全局有效的URI，SBC不做翻译和映射

     Contact属性扩展方案：在Contact中的URI扩展“Global”熟悉，表明传递的URI是一个全局有效地URI，SBC发现此属性后，不对此URI做转换。

3.2.1.         P-AI方案分析
    基于P-AI的方案是阿尔卡特网络平台、华为的软终端中采用的方案。由于P-AI是网络中用来标识用户身份的一个参数， 由P-CSCF插入，没有特殊原因，网络中的其他设备都不会修改它，因此，采用P-AI传递会议URI可以保证会议URI能够传递到终端，不受中间设备的影响。

    在SIP协议中，P-AI用于在可信的SIP实体之间传递经过验证的用户标识，P-Proxy有可能在转发200 OK消息之前，删除P-AI，这样导致业务不能实现。同时，P-AI用于传递经过验证的用户标识，用P-AI传递业务URI也不太合适，因此，不建议采用这种方案。

3.2.2.       Display Name方案
    这种方案仍然保留了SBC对URI的转换能力，网络中到达终端的URI已经经过了了SBC修改。终端看到的URI和会议服务器上创建的不同，但Display Name中填写的会议名称和会议服务器上创建的会议名称保持一致，SBC不会修改Display Name。

    通过Display Name，能够保证在不同SBC下面的会议参与方看到相同的会议名称。 但会议过程中，终端连接使用的URI在进出SBC中经过了转换。为了保证会议的后续消息采用Out of Dialog、In Dialog的方式都可以成功，SBC对于URI做了全局的映射，这种的映射虽然能够实现业务，但是增加了SBC的复杂性， SBC并不知道后续的会议加入消息何时能够到达，只能根据大多数场景，设置一个转换的有效时间，这样在某些业务场景中，会出现业务不正常。

3.2.3.       上下文分析方案
    Contact 头主要提供SIP、SIPS URI，会话中的后续请求消息通过此URI和UA联系，Contact的用处在RFC 3261中有详细的定地。 RFC 3261中规定，任何一个能够建立会话的请求中都必须包含Contact 头，在SIP的六条基本消息中，只有Invite消息是必须带Contact头的。在这些请求中，Contact中的URI是全局有效的，也就是说，如后后续的请求采用Out of Dialog的方式发送，UA也应该收到请求消息。

    在会议中，会议工厂创建了会议实例，通过200 OK中的Contact传送给会议的参与方的UA，并通过设置“isfocus”属性表明这一个“focus”。从业务逻辑的含义来说，这里的URI也是全局的，SBC应该能够分析出这种场景，在这种场景中对于Contact中的URI不做映射。

    这种方案需要SBC能够分析业务场景，在会议的场景中不做URI的映射。为了实现这种功能，SBC必须保持前后的消息的状态，增加了SBC实现的 复杂性；同时，“isfocus”属性只是表明所传的URI是一个“focus”，并不表明这是一个全局的URI，采用这种方式不能保证将来对所有的业务能够成功适应。

3.2.4.       SIP头扩展方案
    SIP头的扩展方案中，采用在SIP消息层面扩展Global-Contact头，明确说明这是一个全局的URI，SBC对于全局的Global-Contact头不做处理。在会议中， 会议工厂创建会议之后，把会议URI放在Global-Contact头中会送到UE。

    这种方案通过在SIP协议中扩展相应的头，可以解决这个问题，但是，我们认为IMS网络中原来存在Contact字段， 可以用户传递URI，这里的专门扩展一个SIP消息头没有必要。

3.2.5.       Contact属性扩展方案
    在RFC3261中规定，在能够建立会话的请求消息中， Contact中传递的URI是全局的， 在其他消息中，SIP消息没有这种含义。在会议类业务中，3GPP的规范规定，Contact中传递的是全局的会议标识的URI，而这种行为在SIP协议中并没有约定[4]。 因此，在会议类业务，或者其他需要传递全局URI的场景中，在Contact中扩展“Global”属性是合理的。

    扩展“Global”属性后，SBC可以明确判定会议工厂返回的URI是全局的URI，使得会议URI可以透明的传递到终端。此外，由于IMS网络和业务无关的，扩展的这种机制能够增强IMS网络适应性。

3.3.       解决方案总结
       SBC是为了满足IMS网络支持固定网络IP接入而引入的一个实体，SBC插入在P-CSCF和终端之间，SBC修改会话中的地址信息，保证地址空间的不重叠。 目前，3GPP的IMS规范、IETF的SIP规范并没有考虑到在消息传递路径中插入SBC对于业务的影响，导致在会议中，会议的URI不能正常传递到终端。

       从构建一个可管理、可维护的IMS网络的角度看， 在固定IP接入网和IMS网络之间引入SBC的实体是合理的， 它可以完成地址空间隔离、媒体整形、合法监听等IMS网络无法很难实现的功能。在会议中出现的问题是由于会议业务采用SIP协议200 OK的Contact传递会议URI，而这种应用场景在SIP中没有明确指示这是一个全局URI而导致的， 因此，作者认为在Contact头中扩展“Global”属性的方法是比较合理的解决方案，同时，扩展的这种机制也可以支持其他的类似场景。

4.    总结
    IMS网络是3GPP定义未来网络的架构，是移动运营商核心网演进的方向，它与接入网络无关， 可以实现固定网络和移动网络融合，但在IMS网络的具体部署中如何支持公网、私网IP接入？如何解决IPV4地址空间不够的问题？在中国移动CM-IMS山西试验网中，我们在此方面做了一些尝试和探索。

    通过在IMS网络边缘引入SBC，可以把IMS网络分为多个独立的地址空间，有效解决IPV4地址不够、网络的安全、合法监听等问题。 虽然引入SBC之后，会对原来IMS定义的业务产生一定的影响，例如，会议标识URI传递问题，但这些问题都可以通过完善3GPP规范、RFC标准实现。