3.5.1穿越问题的起源
为园区网、企业网和个人用户提供软交换呼叫中心业务需要解决防火墙（FW）和地址转换设备（NAT）的穿越问题。
1.单纯防火墙设备引出的问题
出于安全考虑，常规的防火墙配置要求内部网先往外部主机发送包后才打开相应的外部主机发往内部主机的端口，对于外部网主机首先发往内部网主机的包会丢弃。对于UDP,防火墙一般还会对已开启的端口进行检查，超过一定时间没有通信流量就自动关闭端口。
图3-18 防火墙seh设备问题的产生
软交换呼叫中心业务的信令连接可以使用TCP或UDP,使用UDP就会遇到端口定时关闭的问题，造成防火墙内终端不能正常作为被叫。图3-18中以一个位于防火墙之后的SIP终端为例说明了防火墙的存在对呼叫信令的影响，在图中，防火墙的端口生存时间假设为3min。
软交换呼叫中心业务媒体使用UDP连接，由于通话中媒体流不出现双方长时间中断的情况，防火墙设备并不会给通话带来影响。
2.地址转换设备的穿越问题
地址转换设备实现内外网地址的转换，使得内部网络大量用户可以公用有限的公有IP地址资源，同时也可以有效地隐藏内部网络结构，一定程度上保护内部网络的安全。
地址转换机制分为静态地址分配和动态地址分配两大类，通常的设备可以同时支持两种分配方式。静态地址分配是由管理员设置好内外地址的一一对应表，十般用于内部网中需要外部网络访问的设备，如Web服务器、邮件服务器等。动态地址分配是用户消息到达设备时由设备从地址池中按照轮询等机制自动选出外部地址，建立地址映射。
端口转换设备是地址转换设备的扩展，它可以实现IP地址+TCP/UDP端口地址的映射，更有效地利用IP地址。在下面的讨论中，没有特别说明的地址转换设备既包括了地址转换设备也涵盖了端口转换设备，统一简称为NAT。
用户使用软交换呼叫中心业务时使用的信令协议主要有SIP、MGCP和H.248三大类，这些协议消息体中会携带用于后续信令通信和媒体通信的IP地址和端口号。当用户在私网内发出这些消息时，这类消息内容中使用了私有地址，由于NAT只解读替换网络层（IP地址）和传输层（端口地址）数据，用户信令消息的私有地址不能更换，该消息到达对端设备后无法正确处理，正确的通话信令流程无法建立。图3-19中以一个位于地址转换设备之后的SIP终端发出的INVITE消息为例，说明了地址转换设备引出的问题。
图3-19 NAT设备wen问题的产生（SIP：INVITE消息为例）
不同工作方式的NAT都会对软交换呼叫中心业务造成影响，但解决方案会有所不同。在后续的解决方案中将提到这些区别，为帮助理解，下面的内容将简单介绍一下地址转换设备的不同工作方式。
NAT设备可分为全向(FullCone)、部分/限制(Partial/RestrictedCone)和对称(SymmetricCone)三类，它们的区别主要在于如何处理外部网络发来的数据包，在图3-20中分别举例说明了这三种工作方式。
图3-20 三种NAT工作方式示意图
3.5.2 穿越问题的整体解决思路
1.防火墙问题
单纯的防火墙问题的解决思路有两个：
1)使用TCP传送信令；
2)以短于防火墙端口开启时长的周期不断发送消息，维持该信令端口的开启。
采用第二种解决方案时，为了防止出现外部网络中断导致防火墙端口关闭，在网络恢复后软交换呼叫中心不能找到用户终端的情况，维持端口开启的信息最好由终端定期发起，图3-21是方案的示意图。
2.地址转换设备问题
软交换呼叫中心业务穿越NAT设备的解决方案需要考虑到不同种类NAT设备的实现，需要同时解决信令和媒体两方面的问题，NAT穿越的解决方案较防火墙穿越复杂得多。
在NAT信令穿越的实现上一般有三种处理方法：
1)在SIP消息Via和Contact中填入正确的外网可访问的IP地址和端口地址；
2)软交换呼叫中心(或信令代理设备)从SIP消息的IP报头获得IP地址和端口地址，并使用该地址发送应答消息，不再使用Via和Contact参数回应；
图3-21 防火墙设备问题的一种解决方案（消息以SIP为例）
3)隧道方式，所有内部网的消息由专门设备（或软件）打包，通过防火墙的某一特定端口送到外部网特定服务器，由外网服务器与软交换呼叫中心联系。
在NAT媒体穿越的实现上也有三种处理方法：
1)在SDP消息c、m参数中填入正确的外网可访问的IP地址和端口地址；
2)使用媒体中继设备，要求用户的媒体流都发往该设备，由该设备转接；
3)隧道方式，同信令的处理。
综合考虑信令穿越和媒体穿越，形成了各种穿越解决方案。
下面对一些典型的穿越方案进行介绍。
3.5.3终端预写入地址解决方案
穿越问题的起源是消息中含有私有地址，如果能预先得到公网出口IP地址和端口地址（包括信令和媒体），并由终端直接写入消息中就可以实现NAT设备的穿越了。
目前，终端直接获得经NAT后的公网IP地址和端口地址的方式有三类：
1.NAT设备作静态配置
NAT为内部网每一个有固定IP地址的软交换呼叫中心终端分配一个信令通信地址/端口和若干个媒体通信地址/端口，由终端初始化设置时将地址写入，之后由终端发出的消息都直接携带了正确的外部网端口/地址。
由于NAT的配置需要根据用户添加、内部地址变化等情况进行人工更改，端口的分配也要预先进行规划，这种方式不适合在大中型的内部网中使用，主要用于家庭和小型办公室网络环境。
2.终端和NAT间通过协议交互信息（如UPnP（UniversalPlugandPlay））
UPnP架构由Microsoft推动，即插即用（PnP）功能让系统的安装、配置和外围设备添加更方便，而UpnP就是将这一概念扩展到整个网络，自动发现和控制各种网络设备和业务，实现用户“零配置”。UpnP使用标准的TCP/IP协议，参与UpnP架构讨论和实施的主要是计算机终端/网络、家庭自动化、家电、移动设备等厂商和视音频应用提供商等家庭应用服务商。
UpnP的IGC(InternetGatewayDevice)工作委员会针对NAT穿越问题提出了僻决方案,通过支持UpnP的终端设备与支持UpnP的NAT之间的通信，可以获得NAT分配的公有地址,可以要求NAT设备列出当前可用端口列表、添加/删除端口映射条目、指定映射条目生存时间等。如Microsoft在WindowsXP和WindowsME两种操作系统中提供了相关的API,应用程序可利用这些API在消息内容中自动写入正确IP地址。
由于这种机制涉及与网络设备的通信，在大中型企业网络中可能引发安全问题，因此，这种方式应用场合主要定位在家庭网络和小型的办公网络。
3.终端使用特定协议与外部网络指定设备通信获得信息(如STUN)
STUN(RFC3489：SimpleTYaversalofUDPThroughNetworkAddress)由IETF的MIDCOM工作组推出，其工作原理是通过STUN客户端与放置于公共互联网上的一个或多个STUN服务器进行通信，向客户端返回通信中客户端使用的公网IP地址和端口地址，客户端通过返回参数可以判断出自己在网络中的状况。STUN协议消息只有三个请求参数和三个响应参数，协议实现比较简单。STUN可区分的用户端状态有：处于公共互联网、处于关闭了UDP端口的防火墙之后、处于地址转换设备之后，并可以判断出具体的地址转换设备种类——全向NAT、地址限制NAT、端口限制NAT或对称NAT。
利用STUN进行FW/NAT穿越时，软交换呼叫中心终端作为STUN客户端㊀，STUN服务器可以单独设置，也可以将这部分功能置入软交换呼叫中心设备中。
利用STUN实现穿越的优点是内部网络结构和NAT/FW设备无需对现有设备做任何改动，可以应用在多个NAT级联的内部网络中；问题是应用场合受到NAT种类的限制，该方式对目前使用越来越多的对称防火墙无效。虽然IETF中出现了应用STUN实现对称防火墙穿越的提案，但使用过程复杂，并不能适用于所有的穿越情况。
3.5.4 MlDCOM方案
中间设备(如FW和NAT)的使用对很多的应用都有影响，为了统一解决这类问题，IETF的MIDCOM(Middlebox Communication)工作组研究制定相关建议和标准，希望能系统地解决这一类问题。MIDCOM工作组致力推出MIDCOM协议，但目前MIDCOM协议只完成框架架构、需求、可能使用的协议评估等前期工作，具体的内容还在标准化进程中。
MIDCOM的框架结构是采用可信的第三方(MIDCOMAgent)对Middlebox(NAT/FW)进行控制的机制，应用业务识别的智能也由Middlebox转移到外部的MIDCOM Agent上，因此应用协议对Middlebox是透明的。由于应用业务识别的智能从Middlebox移到外部的MIDCOM Agent上,根据MIDCOM的架构，在不需要更改Middlebox基本特性的基础上，通过对MIDCOMAgent的升级就可以支持更多的新业务，这是相对由FW/NAT分析应用层协议方式的一个很大的优势。
在软交换呼叫中心业务实际应用中,Middlebox功能可驻留在NAT/FirewaU,通过软交换呼叫中心设备(即MIDCOM Agent)对SIP、MGCP/H.248协议的识别和对NAT/Firewall的控制，实现FW/NAT设备的业务穿越。
MIDCOM方案的提供时间是个问题，MIDCOMAgent与Middlebox之间的具体通信协议标准尚未确定，可能的协议有SNMPv3、RSIP、Megaco,Diameter和COPS等，完成协议的选定和具体消息及参数的确定以目前工作组的进度看需时一年以上。
3.5.5 应用层网关方案
应用层网关方案是通过在FWZNAT设备中镶嵌ALG程序或在内部网出口独立设置的ALG设备来解决FW/NAT穿越问题。
ALG通过分析相关的应用层协议，转换相关的消息参数。在信令建立阶段，ALG预分配媒体端口地址，建立内外端口之间的映射，呼叫建立后，ALG按媒体端口映射表进行媒体的转发。ALG通过检查软交换发来的INVITE消息中SDP参数o、m、c,可以发现呼叫双方是否都在内部网中，对于内部通话，媒体流不再需要通过ALG。
ALG方案主要定位是企业级的穿越解决方案，通过购买独立的ALG设备或含有ALG功能的FW/NAT,可以实现企业内部网与外界一个或多个软交换呼叫中心运营商的通信。
考察当前市场上主流的FW/NAT设备对几种VoIP的支持情况，可以看到：目前，对于互联网上仍占主导地位的VoIP一H.323协议，大量的企业网级产品都已经可以支持语音、图像等业务的穿越；随着SIP的使用量增加，主流厂商陆续开始支持SIP的穿越；对于MGCP和H.248/Megaco协议，则基本还处于研发过程中。
3.5.6协议扩展加媒体代理
SIP在设计时并没有考虑到防火墙和地址转换设备的问题，如果能单纯通过在协议中增加消息或参数的方式来解决NAT穿越问题，可以减少中间设备，减少互通性和业务升级等问题。
IETF中出现了一些相关的SIP消息参数修改的草案，下面列出几个扩展的消息和参数：
1）在SIP消息中received参数的基础上再增加iport参数记录端口地址，作为正确的消息响应地址；
2）增加参数供用户描述是否在FW或NAT或FW+NAT之后，如Firewall参数或Translate参数等；
3）在SDP中增加a=direction:active,以确定用户是先发媒体流还是在收到对方媒体流之后用该消息地址作为回应地址发送媒体流。该消息可以解决一端在NAT之后的用户通信问题，但双方都在NAT之后的情况还是无法解决。
由于没有合适的消息参数可以解决NAT之后用户的媒体通信问题，协议扩展的方式还需要与媒体代理设备一起使用。这种情况下，软交换呼叫中心需要与媒体代理设备之间进行通信，这种通信协议目前也未制定标准，目前工作在该方式的设备使用的都是私有协议。
方案同样需要解决媒体安全接续的问题，但目前方案使用的最大障碍是由于没有标准可循造成的互通性问题。
3.5.7隧道穿越方案
这里所指的隧道方案不是指私网用户直接建立隧道到软交换呼叫中心的方案。
隧道穿越方案是由位于内部网络的隧道代理设备将用户信令和媒体统一打包，通过一个或一对端口传送到位于外部网络的隧道服务器设备，由隧道服务器将用户消息区分开，并进行信令内容的解析和替换，送往软交换呼叫中心或通信对端处理。隧道代理设备和隧道服务器设备之间的杪议目前没有标准，目前支持该方案的厂商都使用私有通信协议。
3.5.8 信令媒体全代理
信令媒体全代理方式是通过对私网内用户呼叫的信令做代理，对用户媒体做中继的方式解决NAT穿越问题。
内部网终端使用代理设备地址作为信令的通信地址，当用户注册消息到达代理设备时，代理设备记录信令包的源IP和端口地址，在后续消息中使用该地址与用户通信。用户呼叫时，代理设备记录协议中携带的私网地址和端口信息，同时为主被叫用户预分配用于媒体中继的公网IP和端口地址，并使用分配的公网地址作为媒体通信端口重新生成信令消息发往软交换呼叫中心。当信令过程建立后，代理设备在预先分配的媒体端口上等待接受媒体，将接收的媒体按预先建立端口地址表进行转发。
对于用户，信令媒体全代理方式对终端没有特殊的要求，也无需对现有内部网络做改动，由于通信对端媒体的地址固定为代理设备地址，在防火墙设置端口打开策略时可以指定对端地址，提高了内部网的安全性。
信令媒体全代理方案使用中的注意事项和存在问题有以下几点：
1）用户的收发媒体必须在同一端口上。
2）单向媒体通道的建立，当需要建立去往用户的单向媒体通道时，比如SIP呼叫建立阶段使用的183消息和MGCP中的RECIEVE-ONLY模式，由于用户端没有发送媒体流，媒体中继设备不能获得用户的媒体端口，也就无法将服务器等设备发出的媒体送往用户。这个问题可以通过强制用户端发送媒体流来解决。
3）媒体通道接续的安全。在方案和设备实现上，如何保证媒体通道接续的安全、预防媒体假冒是当前需要解决的问题。
信令媒体全代理方案是目前适宜运营商使用的面对所有用户的解决方案。在运营商的软交换呼叫中心网络组织中，通过利用该方案中设备进行软交换呼叫中心应用层协议处理和媒体转发的特点，可以将设备功能衍生致软交换呼叫中心安全防护、软交换呼叫中心业务质量区分标记、媒体定向等方面，将穿越代理设备扩展成为边缘接入控制设备，成为软交换呼叫中心网络边缘的守门人。
3.5.9综合解决方案
前面提到了多种技术方案，都有各自适用范围和限制，能否将多种方案结合起来，对用户提供一个简单方便全面的穿越解决方案？目前有些方案正在尝试实现这一点，IETF的MMUSIC研究组中提出了交互连接建立草案（ICE,Interactive ConnectivityEstablishment）。图3-22和图3-23介绍了其中一种方案示意图。
要决定用什么样的穿越方案首先要明确用户网络环境，因此，综合方案的第一步是探测用户网络端口开启情况和网络NAT情况。
当用户UDP可用时，用户网络NAT情况的探测可以结合用户网络NAT端口预开启、信令扩展等方案，将可能联通的端口通过信令全部告诉用户，由用户端测试连通性并选择可用的以达到端口传送媒体，当所有端口均无法连通时，启动代理方式。
图3-22 用户网络端口开启情况探测和处理
图3-23综合解决方案的一个示例
实际完成一个综合的全面的穿越解决方案要比这个示例复杂得多，主被叫双方探测结果的各种组合、端口预开启的安全性、可连通通道的优先次序、协议扩展的方式等等都需要深入考虑。由于探测过程和方案选择过程比较复杂，.这种方式仅限于在软终端实现。
3.5.10穿越方案的选择
软交换呼叫中心业务穿越FW/NAT的技术还在发展，新的协议草案和协议使用方法不断推出，设备也在不断完善中。面对众多的穿越解决方案，由于运营商、企业、个人用户等对穿越NAI7FW的方案要求有着不同的侧重点，方案选择也各有不同。表3-1对一些方案进行了技术比较。
表3-1 穿越解决方案的技术比较
在目前比较成熟可投入商用的方案中,NAT静态配置较适宜个人和小型办公室用户使用,ALG方案较适宜企业和园区进行部署，对于软交换呼叫中心业务运营商，信令媒体全代理、协议扩展+媒体代理和隧道穿越都是可选方案，方案的选择要结合软交换呼叫中心的组网、业务量、目标用户、安全、服务质量等因素统一考虑。
