NAT对语音业务的影响(终端控制方案…

NAT对VOIP业务（SIP）的影响

      下面的SIP流程与码流摘自

3GPP TR 24.930 IP Multimedia core network Subsystem (IMS)

based on Session Initiation Protocol (SIP)

and Session Description Protocol (SDP);

Stage 3

  

Table 5.5-1: INVITE request (UE#1 to IM CN Subsystem entities)

INVITE tel:+1-212-555-2222 SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: ,

P-Preferred-Identity: "John Doe"

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11

Privacy: none

From: ;tag=171828

To:

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Contact:

Allow: INVITE, ACK, CANCEL, BYE, REFER, MESSAGE

Content-Type: application/sdp

Content-Length: (…)

 

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd

s=-

c=IN IP6 5555::aaa:bbb:ccc:ddd

t=0 0

m=video 3400 RTP/AVP 98

b=AS:75

a=rtpmap:98 H263

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=rtpmap:96 telephone-event

 

   从上述invite信令中可以看到以下SIP头中会携带主叫侧的IP地址：

     SIP头中的 Via、Contact,

     SDP行：O行、C行、

   各举一个属性值来描述IP地址对于呼叫建立的影响：

     SIP头中的Contact 描述了主叫用户可用于接受呼叫的SIP URI(常用IP地址表示)。

     SDP中C行的IP地址表示本端用于建收RTP媒体流的IP地址（每个流的端口在m行中携带）

  

   再看看携带SIP信令的IP包的分层结论：

     最上层（应用层）：  SIP信令  ，其中含有本端和远端的IP地址。

     中层（传输层）：  TCP 或UDP 或 SCTP ，其中不含IP地址。

     下层：IP层。其中含有本端和远端的IP地址。

 

     终端从DHCP服务器得到的是私网地址。

    UE A希望呼叫UE B时，UE A首先发出一个含SIP invite的IP包出去，IP头的远端地址是UE B的公网地址。

    边界路由器（内置NAT网关）一般会修改IP层中的源IP为公网IP，而远端UE B收到IP包后，把应用层数据(SIP包）发给SIP协议层（一般是一个SIP终端软件），SIP软件从SIP包中得到远端UE A的Contact并存储下来，在经过一些消息交互后，UE B如想直接发送对话内请求给UE A，必须使用原来收到invite时存储下来的Contact头作为请求的request uri。（上图中UE A从 200 ok中会得到UE B的Contact地址，UE A 发的ACK中的req-uri即UE B的Contact）

    SIP软件不能直接使用的所收到IP头中的远端IP地址放到SIP协议，SIP协议不允许这样做。

    SDP offer\answer交互用于终端双方交换双方的编解码信息与媒体面的IP、端口。这些交互信息在SIP信令中携带，与IP头、SIP头字段中的IP经常是不同的。

 

SIP呼叫穿透NAT的方案

   如NAT边界路由器在发出含invite的IP包时，如不修改SIP协议层、SDP行中的本端IP为私网IP，则被叫UE可以收到这个IP包，但将无法与本端进行SIP通信。 

   可见分配了私网IP的SIP终端，当与外网SIP终端通信时，必须有办法将SIP协议层、SDP中的IP修改为公网IP、或携带公网IP。

   解决方案分两种思路：

思路1：SIP协议IP地址不修改，新增SIP头字段或SDP行用来携带公网地址。   

      比如：因为响应消息发送到SIP via字段所包含的地址和端口号，由于VIA所填的信息在NAT穿越时和实际转换后的地址是不一致的，所以响应消息可能无法正确发送。解决方法是使用RECEIVED字段作为响应的回送地址

注：SIP over UDP时必须让对端知道本端的IP。而当SIP over TCP承载时不存在响应消息回送问题，对话内请求可以使用新的TCP连接，也可共享原连接（即一个对话中的所有请求都使用同一个TCP连接，也含初始请求）。

        对于共享连接情况，SIP新定义了一个头字段，用于通知对端是在 原TCP  IP\端口上监听对话内请求，还是新建TCP连接。

      思路1不能单独存在，必须配合STUN、TURN等协议、或配合SBC使用。

 

思路2：SIP协议中IP地址修改为公网地址。

   围绕着由谁修改SIP协议层的IP这一点，产生了两种 Voip业务穿越NAT 的方案。

    方案1：终端穿越NAT：终端在发出含SIP信令的IP包之前，就已经知道了自己的公网IP，并把SIP协议层（含SDP）中的本端IP、端口全部替换为公网IP、端口。

                    终端负责检测NAT并执行穿越必要的工作，其缺点是需要终端支持相应的协议扩展；

                     需要STUN或TURN服务器。

 

        终端穿越NAT方案的基础是STUN协议，但点到点的通信方式中，无法支持Symmetric NAT。

        TURN是STUN的扩展，引入STUN RELAY Server，提供了穿越Symmetric NAT的方案。 所有通信经过relay sever的中继。

        ICE则综合了STUN\TURN，适合于所有NAT。

        ICE的出现彻底解决了NAT穿越的问题，STUN也不再作为NAT穿越的完整解决方案，而是ICE解决方案的一个具体技术手段。 但ICE需要扩展SIP协议与标准的SDP协商机制。

 

    方案2：网络（业务层网元，而非传输层网元）控制穿越。终端的SIP信令路由到特定网元(SBC，它一般与终端不在同一个网络，可以位于公网)，SBC会修改SIP协议中的私网IP为公网IP。

                    由网络提供NAT穿越服务，终端可以不具备NAT穿越能力。 不需要STUN或TURN服务器，特定网元一般称为ALG或SBC。但由于它们一般不能与NAT网关是同一个设备，则无法检测NAT的类型，所有媒体都要媒体面设备进行中继。但不需要扩展SIP协议。

 

    总之，上述两种方案达到的效果是：被叫侧收到的SIP信令中，所有的IP、端口都已经是公网IP、端口了。

 

服务器的保活机制：

       如果采用STUN服务器\TURN 服务器，可以通过与终端间的STUN保活包来检测终端是否在线，并且让终端侧的NAT网关维护NAT表项。

       如果采用SBC的话，只能通过SIP option消息或终端的注册刷新消息来检测终端是否在线，并且让终端侧的NAT网关维护NAT表项。

   前者的开销较小，STUN保活包很小，几百个字节。

   而Option消息由SIP应用层发送，包稍大，设备性能稍有降低。并且一般几十秒才会发送一次option。

注：SBC必须能频繁检查终端是否在线，这就要求option或终端主动发的注册刷新消息周期很短，比如几分钟，但核心网不需要频繁接受注册刷新消息，所以SBC会吸收一部分注册刷新(维护两个定时器，一个是对于终端，一个是对于核心网)，对核心网来看，注册刷新周期仍是半小时以上。

 

其它方案：

        NAT上安装ALG(Application Level Gateway)，要求升级所有NAT设备为ALG，由ALG来修改应用层协议中的IP地址字段。

        MIDCOM（Middlebox Communication）：需要升级NAT/防火墙以支持MIDCOM协议，且需要在运营商的网络侧部署MIDCOM agent代理。NAT/防火墙收到MIDCOM agent的通知后对对呼叫和媒体流进行映射和转换。

        上述两个方案需要升级NAT设备，可行度较低。

 

最终：VOIP业务穿越NAT的方案总结为三种：

1，升级现网NAT的方案。

2，升级终端+部署TURN 服务器 的方案。

3，传统终端+部署SBC服务器 的方案。

     后2种方案是可商用的方案。

 

在3GPP IMS架构中提到2种NAT穿越的模型，分别见 ICE部分、ALG 部分。

 

STUN协议(让终端发现自己的公网IP\端口)

      RFC3489、RFC5389定义了STUN协议，前者的定义是Simple Traversal of UDP Through NATs，后者的定义是Session Traversal Utilities for NAT。前者基于UDP，后者支持TCP穿透。

        基本的STUN协议：RFC3489，可让UDP穿越Cone NAT)

        

补充的STUN协议：RFC5389，可支持TCP穿透.

        RFC 5389不但让终端得到自己的的公网IP、端口，也可维护终端在NAT网关所绑定表项的保活。    

        它定义了三种STUN用途：

                    Interactive Connectivity Establishment（ ICE）[MMUSIC-ICE]，交互式连接建立

                    Client-initiated connections for SIP [ SIP-OUTBOUND]，用于SIP的客户端初始化连接

                    NAT Behavior Discovery [BEHAVE-NAT]，NAT行为发现

 

STUN协议的基本思想

        解决穿透NAT问题的一个思路是，私网中的终端通过某种机制预先得到出口NAT上的对外地址，然后在净载中所填写的地址信息直接填写出口NAT上的对外地址，而不是私网内终端的私有IP地址，这样净载中的内容在经过NAT时就无需被修改了，只需按普通NAT流程转换报文头的IP地址即可，净载中的IP地址信息和报文头地址信息是一致的。STUN协议就是基于此思路来解决应用层地址的转换问题。

         即：应用层地址由终端来置为公网地址与端口，IP层地址、TCPUDP层端口由NAT网关来置为公网地址。

      

        STUN客户端通过UDP向STUN服务器发送绑定请求消息，STUN服务器收到请求消息后产生响应消息，返回所看到的源地址给客户端（即经过NAT映射后的映射地址）。通过STUN还可以获得客户端所处网络中的NAT的类型（STUN所定义的四种类型）和映射地址的生存时间（没有数据传输的时间超过此时间后映射关系失效）。在信令净载中所填写的地址信息直接填写出口NAT上的对外地址（IP和端口号），而不是私网内终端的私有IP地址和端口号，以告知对端发送数据时应该填写的目的IP地址和端口号。由于STUN协议已经在NAT上建立了映射表现，故可以顺利进行通信。

        优点：STUN协议最大的优点是无需现有NAT/FW设备做任何改动。由于实际应用中，已有大量的NAT/FW，并且这些NAT/FW并不支持P2P应用，如果用MIDCOM或NAT/ALG方式来解决此问题，需要替换现有的NAT/FW，这是不太容易的。同时STUN方式使用与多个NAT串联的网络环境，而MIDCOM方式则无法实现对多级NAT的有效控制。

        缺点：STUN的局限性在于需要终端支持STUN CLIENT的功能，同 时STUN并不适合支持TCP连接的穿越，因此不支持H.323。另 外不支持对称NAT (Symmetric NAT)的穿越。

 

注：STUN 改进而成的STUNT－Simple Traversal of UDP Through NATs and TCP too，可以实现TCP 数据包的通信。但似乎使用面很小。

 

 

STUN的流程

      STUN的目标是：让终端可以发起正式通信前，事先知道 NAT会分配给它的公网IP与端口是什么具体的值、及当前所处的 NAT网络类型。

      STUN是一种Client/Server的协议，也是一种Request/Response的协议，默认端口号是3478。

       STUN方案需要在公网有一个STUN Server。而终端上也必须安装 STUN客户端 软件。 需要防火墙打开STUN协议所需的UDP 端口。

      用户可以通过在自己主机上运行STUN客户端远程连接STUN服务器来确认自身的网络状况（公网IP、端口、NAT类型）

     

       STUN服务器运行在UDP协议之上,它具有两个固定公网地址，通过完成以下2个功能来达到STUN协议的目标。

    1, 告诉STUN客户端经NAT设备映射后的公网地址.

              Server在收到client的UDP包以后，Server将接收到该包的地址和端口利用udp包传回来给 client，client把这些地址和端口与本机的ip地址和端口进行比较，如果不同，说明在NAT后面，否则就位于NAT前面。

    2, 根据STUN客户端的要求,从服务器的其他不同IP或端口向客户端回送包.

               原因是为了检测不同类型的 NAT。STUN协议定义了一些消息属性，要求Server有不同的动作，比如发送响应的时候使用不同的IP地址和端口，或者改变端口等等。

     

    STUN 的简单操作过程：

    发送请求。请求分为两种

    1.Binding Requests, sent over UDP,

     用来发现NAT的公网地址，和MAPPING后的端口

     2.  Binding Response,

    服务器产生Binding Response，并把得到的MAPPINGIP 和端口，返回到客户端， 客户端比较MAPPING地址是否和本机地址相同，如果是说明是本机也是公网，否则判断NAT的类型(判断方法：client uses additional STUN Binding Requests)

    3.Binding Error，

    4.Shared Secret Requests, sent over TLS   over TCP.

           这个请求要求服务器返回 一临时用户名和密码，用来下一步的Binding Requests/ Response,用来验证信息的完整性

    5.Shared Secret Response,

    6 Shared Secret Error Response。

 

NAT网络类型

     STUN协议认为NAT对待UDP的实现方式有4种，分别如下：

1.    Full Cone NAT

   完全锥形NAT，所有从同一个内网IP和端口号发送过来的请求都会被映射成同一个外网IP和端口号，并且任何一个外网主机都可以通过这个映射的外网IP和端口号向这台内网主机发送包。

   即：  从主机UDP端口A发出的数据包都会对应到NAT设备出口IP的端口B,并且从任意外部地址发送到该NAT设备UDP端口B的包都会被转到主机端口A.

2.    Restricted Cone NAT

   限制锥形NAT，它也是所有从同一个内网IP和端口号发送过来的请求都会被映射成同一个外网IP和端口号。与完全锥形不同的是，外网主机只能够向先前已经向它发送过数据包的内网主机发送包。

  即：  从主机UDP端口A发出的数据包都会对应到NAT设备出口IP的端口B,但只有从之前该主机发出包的 目的IP发出到该NAT设备UDP端口B的包才会被转 到主机端口A.

3.    Port Restricted Cone NAT

   端口限制锥形NAT，与限制锥形NAT很相似，只不过它包括端口号。也就是说，一台IP地址X和端口P的外网主机想给内网主机发送包，必须是这台内网主机先前已经给这个IP地址X和端口P发送过数据包。

   即：  从主机UDP端口A发出的数据包都会对应到NAT设备出口IP的端口B，但只有从之前该主机发出包的 目的IP/PORT发出到该NAT设备 UDP端口B的 包才会被转到主机端口A.

4.    Symmetric NAT

   对称NAT，所有从同一个内网IP和端口号发送到一个特定的目的IP和端口号的请求，都会被映射到同一个IP和端口号。如果同一台主机使用相同的源地址和端口号发送包，但是发往不同的目的地，NAT将会使用不同的映射。此外，只有收到数据的外网主机才可以反过来向内网主机发送包。

   即：    即使数据包都从主机UDP端口A发出,但只 要目的地址不同,NAT设备就会为之分配 不同的出端口B.

 

     前面3重NAT，被映射的公网  PORT 和 IP，是根据终端内网的IP和端口决定的。如果终端的内网IP和端口相同，那么被映射后的端口和地址是固定。这个功能为VOIP 穿越提供了很好条件。

    第4种NAT，打洞后的MAPPING 地址和端口将变地不可靠。很难穿越。

 

    这4种加上以下的三种，称为 NAT网络类型。

    1, Opened: 即主机拥有公网IP,并且没有防火墙, 可自由与外部通信.

    2, Symmetric UDP Firewall: 主机出口处没有NAT设备,但有防火墙,且防火墙规则如下:

          从主机UDP端口A发出的数据包保持源地址,但只有从之前该主机发出包的目的IP/PORT发出到该主机端口A的包才能通过防火墙.

    3, Blocked: 防火墙限制UDP通信.

 

STUN中发现NAT网络类型   

通过STUN，得到NAT类型的过程可概括如下:

    1, STUN客户端向STUN服务器发送请求,要求得到自身经NAT映射后的地址:

        a,收不到服务器回复,则认为UDP被防火墙阻断,不能通信,网络类型:Blocked.

        b,收到服务器回复,对比本地地址,如果相同,则认为无NAT设备,进入第2步 ,否则认为有NAT设备,进入3步.

    2, (已确认无NAT设备)STUN客户端向STUN服务器发送请求,要求服务器从其他IP和PORT向客户端回复包:

        a,收不到服务器从其他IP地址的回复,认为包被 前置防火墙阻断,网络类型:Symmetric UDP Firewall.

        b,收到则认为客户端处在一个开放的网络上,网络类型:Opened.

    3, (已确认存在NAT设备)STUN客户端向STUN服务器发送请求,要求服务器从其他IP和PORT向客户端回复包:

        a,收不到服务器从其他IP地址的回复,认为包被前置NAT设备阻断,进入第4步.

        b,收到则认 为NAT设备类型为Full Cone,即网络类型:Full Cone NAT.

    4, STUN客户端向STUN服务器的另外一个IP地址发送请求,要求得到自身经NAT映射后的地址,并对比之:

        a,地址不相同 ,则网络类型:Symmetric NAT.

        b,相同 则认为是Restricted NAT,进入第5步,进一步确认类型.

    5, (已确认Restricted NAT设备)STUN客户端向STUN服务器发送请求,要求服务器从相同IP的其他PORT向客户端回复包:

        a,收不到服务器从其他PORT地址的回复,认为包被前置NAT设备阻断,网 络类型:Port Restricted cone NAT.

        b,收到则认为 网络类型: Restricted cone NAT.

 

        一旦客户端得知了Internet端的UDP端口，通信就可以开始了。如果NAT是完全圆锥型的，那么双方中的任何一方都可以发起通信。如果NAT是受限圆锥型或端口受限圆锥型，双方必须一起开始传输。

          以上的响应同时还使得STUN客户端能够确定正在使用的NAT类型——因为不同的NAT类型处理传入的UDP分组的方式是不同的。四种主要类型中有三种是可以在STUN中使用的：完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT——但大型公司网络中经常采用的对称型NAT（又称为双向NAT）则困难较大。

 

 

 

TURN协议(提供Relay server，穿越Symmetric NAT)

          TURN，在RFC5766中定义，英文全称Traversal Using Relays around NAT（TURN）：Relay Extensions to Session Traversal Utilities for NAT（STUN），即使用中继穿透NAT：STUN的中继扩展。简单的说，TURN与STUN的共同点都是通过修改应用层中的私网地址达到NAT穿透的效果，异同点是TURN是通过两方通讯的“中间人”方式实现穿透。

        如果一个主机位于NAT的后面，在某些情况下它不能够与其他主机点对点直接连接。在这些情况下，它需要使用中间网点提供的中继连接服务。TURN协议就是用来允许主机控制中继的操作并且使用中继与对端交换数据。TURN与其他中继控制协议不同的是它能够允许一个客户端使用一个中继地址与多个对端连接。

        TURN协议被设计为ICE的一部分，用于NAT穿越，虽然如此，它也可以在没有ICE的地方单独使用。

 

TURN协议的基本思想

        TURN应用模型通过分配TURN Server的地址和端口作为私网终端对外的接受地址和端口，即私网终端发出的报文（除了信令）均通过TURN Server进行Relay转发。

        TURN方式解决NAT问题的思路与STUN相似，也是私网中的终端通过某种机制预先得公网上的服务地址 (STUN方式得到的地址为出口NAT上外部地址，TURN方式得到地址为TURN Server上的公网地址)，然后在报文净载中所要求的地址信息就直接填写该公网地址。

        TURN方式能够解决所有类型的NAT穿越问题。与STUN方式比较，TURN方式除了具有STUN方式的优点外，还解决了STUN应用无法穿透 对称NAT(Symmetric NAT)以及类似的Firewall设备的缺陷，同时TURN支持基 于TCP的应用，如H.323协议。此外TURN Server控制分配地址和端口，能分配RTP/RTCP地址对(RTCP端口号为RTP端口号加1)作为私网终端用户的接受地址，避免了STUN方式中出口NAT对RTP/RTCP地址端口号的任意分配，使得客户端无法收到对端发来的RTCP报文(对端发RTCP报文时，目的端口号缺省按RTP端口号加1发送)。

        TURN的局限性在于需要VOIP终端支持TURN Client，这一点同STUN一样对网络终端有要求。此外，所有报文都必须经过TURN Server转发，增大了包的延迟和丢包的可能性。

 

TURN内容

            在公网中有一个TURN服务器。在因特网的别处有一个或多个对端是这个TURN客户端希望通讯的。这些对端也有可能是在一个或多个NAT的后面。该客户端使用服务器作为 一个中继来发送数据包 到这些对端去，并且从这些对端接收数据包。

            客户端通过一个IP地址和端口的组合来与服务器建立会话。客户端使用TURN命令在服务器上创建和操作一个ALLOCATION。一旦这个allocation创建好了，客户端能够在数据发往哪个对端的指示下发送应用数据到这个服务器，服务器将中继这些数据到合适的对端。客户端发送的应用数据包含在TURN消息中，服务器将数据提取出来，并以UDP数据包方式发送给对端。反向上，对端以UDP数据包方式发送应用数据到这个allocation提供的中继传输地址。因为TURN消息总是包含客户端与哪些对端通讯的指示，客户端能够使用单一的allocation来与多个对端通讯。

 

       TURN协议在语法和操作上均与STUN相似（实际上是 扩展了STUN方法，引入了STUN RELAY Server ），其优点是提供了 对 对称性(Symmetric)NAT 的穿越。处在公网 的TURN服务器为客户端提供本身的一个外部IP地址和端口，并且负责中转通信双方的媒体流。TURN协议虽然支持所有类型的NAT穿越，但是它需要中转通信双方的媒体流，使得媒体流在传输过程中增加了一跳，不可避免地增加了包的延迟和丢包的可能性，而且完全使用TURN方式需要大量的TURN服务器，在有大量用户时，TURN服务器会成为系统瓶颈。

    

       TURN可以申请Relay Server上多个连续端口的，以便可以适用RTP这种需要成对端口的协议。

 

TURN与STUN的类似之处：

私网中的终端通过某种机制预先得到公网上的服务地址，然后在报文净载中所要求的地址信息就直接填写该公网地址。

 

TURN与STUN的区别：

STUN得到的地址为出口NAT上外部地址；TURN得到的地址为TURN Server上的公网地址

TURN支持Symmetric NAT

TURN支持基于TCP的应用，如H.323

 

ICE协议

        没有通用和万能的NAT/FW穿越方法，各种因素都会影响到某种具体的穿越技术的成败和效果，而在任何一种具体的网络场景和NAT/FW类型组合中，可能都需要联合使用多种穿越手段才能奏效。ICE(Interactive Connecting Establishment)就是基于此种思想而来的，其通过综合运用几种协议（STUN、TURN等），使之在最适合的情况下工作，以弥补单独使用其中任何一种所带来的固有缺陷。ICE并没有修改所综合运用的协议，能同时具备各个协议所具有的优点。在居于终端的NAT穿越的方法中，ICE是首要选择。

        ICE可以返回三类地址（即IP和端口号）：1、客户端的本地地址；2、出口NAT上的对外映射地址；3、类似于TURN的中继转发地址。给这些地址分配不同的优先级，通过一定的算法对两个节点间的此三类地址对进行 连通性测试，就可以选择最好的地址建立连接。ICE可以适用于所有的NAT类型。

        与STUN和TURN相比，ICE并非是解决NAT穿透问题的协议，而是一个框架，在这个框架中，可以整合其他现存的NAT穿透协议，如STUN、TURN、RSIP等。区别于其他的NAT穿透解决方案，ICE是一种探索和更新式的解决方案，通过搜集自身和对端尽可能多的网络信息（各种网络地址），尝试在这些地址间建立数据通道，并在这一过程中不断更新先前收集到的信息，从而找出和选择能够进行NAT穿透的数据通道。

        

        ICE方式的优势是显而易见的，它消除了现有机制的许多脆弱性，具有广泛的适应能力以及对IPV6网络的支持，是一种综合的解决方案。

        例如传统的STUN有几个脆弱点，其中一个就是发现过程需要客户端自己去判断所在NAT类型，这实际上不是一个可取的做法。 而应用ICE之后，这个发现过程已经不需要了。

        另一点脆弱性在于STUN、TURN等机制都完全依赖于一个附加的服务器，而ICE利用服务器分配单边地址的同时，还允许客户端直接相连，因此即使STUN或TRUN服务器中有任何一个失败了，ICE方式仍可让呼叫过程继续下去。

 

        此外，传统的STUN最大的缺陷在于它不能保证在所有网络拓扑结构中都正常工作，最典型的问题就是Symmetric NAT。对于TURN或类似转发方式工作的协议来说，由于服务器的负担过重，很容易出现丢包或者延迟情况。

        而ICE方式正好提供了一种负载均衡的解决方案，它将转发服务作为优先级最低的服务，从而在最大程度上保证了服务的可靠性和灵活性。

 

        此外，ICE的优势还在于对Ipv6的支持。

 

       ICE总结：

利用STUN/TURN/RSIP/MIDCOM

客户端有专门的逻辑

ICE说明如何使用其他协议穿越NAT

ICE的属性

            如果有，总能找到一种适合的通信方式

            总能找到中继最少的通信方式

            总能找到通信代价最小的路径

            不需要了解拓扑、NAT的类型等任何信息

            能够保证不会出现只振铃、无媒体流的情形发生

 

ICE的流程

          对于SIP，为ICE定义了一些新的SDP行：anat属性。

     

 

 算法流程

1      收集传输地址

会话发起者需要收集的对象包括本地传输地址(Local Transport Address)和来源传输地址(Derived Transport Address)。本地传输地址通常由主机上一个物理(或虚拟)接口绑定一个端口而获得。会话发起者还将访问提供UNSAF(Unilateral self-address fixing)的服务器，例如STUN、TURN或TEREDO。对于每一个本地传输地址，会话者都可以从服务器上获得一组来源传输地址。

 

显然，实现物理或虚拟连通方式越多，ICE将工作得越好。但为了建立对等通信，ICE通常要求至少有一个来源地址由位于公网上的中继服务器(如TURN)所提供的，而且需要知道具体是哪一个来源传输地址。

 

2      启动STUN

会话发起者获得一组传输地址后，将在本地传输地址启动STUN服务器，这意味着发送到来源地址的STUN服务将是可达的。与传统的STUN不同，客户端不需要在任何其它IP或端口上提供STUN服务，也不必支持TLS， ICE用户名和密码已经通过信令协议进行交换。

 

客户端将在每个本地传输地址上同时接受STUN请求包和媒体包，所以发起者需要消除STUN消息与媒体流协议之间的歧义。在RTP和RTCP中实现这个并不难，因为RTP与RTCP包总是以0b10(v=2)打头，而STUN是0b00。对于每个运行STUN服务器的本地传输地址，客户端都必须选择相应的用户名和密码。用户名要求必须是全局唯一的，用户名和密码将被包含在初始化消息里传至响应者，由响应者对STUN请求进行鉴别。

 

3      确定传输地址的优先级

STUN服务器启动后，下一步就是确定传输地址的优先级。优先级反映了UA在该地址上接收媒体流的优先级别，取值范围在0到1之间，通常优先级按照被传输媒体流量来确定。流量小者优先，而且对于相同流量者的Ipv6地址比Ipv4地址具有更高优先级。因此物理接口产生的本地Ipv6传输地址具有最高的优先级，然后是本地Ipv4传输地址，然后是STUN、RSIP、TEREDO来源地址，最后是通过VPN接口获得的本地传输地址。

 

4      构建初始化信息(Initiate Message)

    初始化消息由一系列媒体流组成，每个媒体流都有一个缺省地址和候选地址列表。缺省地址通常被Initiate消息映射到SIP信令消息传递地址上，而候选地址列表用于提供一些额外的地址。对于每个媒体流来说，任意Peer之间实现最大连通可能性的传输地址是由公网上转发服务器(如TURN)提供的地址，通常这也是优先级最低的传输地址。客户端将可用的传输地址编成一个候选地址列表(包括一个缺省地址)，并且为每个候选元素分配一个会话中唯一的标识符。该标识符以及上述的优先级都被编码在候选元素的id属性中。一旦初始化信息生成后即可被发送。

 

5      响应处理：连通性检查和地址收集

会话应答方接收到初始化信息Initiate Message后，会同时做几个事情：首先，执行2.3.1中描述的地址收集过程。这些地址可以在呼叫到达前预收集，这样可以避免增加呼叫建立的时间。当获得来源地址以后，应答方会发送STUN Bind请求，该请求要求必须包含Username属性和Password属性，属性值为从 “alt”中得到的用户名和密码。STUN Bind请求还应包括一个Message-Integrity属性，它是由Initiate Message中候选元素的用户名和密码计算得来的。此外，STUN Bind请求不应有Change-Request或Response-Address属性。

 

当一个客户端收到Initiate Message时，它将通过其中缺省地址和端口发送媒体流。如果STUN Bind请求消息引起错误应答，则需要检查错误代码。如果是401，430，432或500，说明客户端应该重新发送请求。如果错误代码是400，431和600，那么客户端不必重试，直接按超时处理即可。

 

6      生成接受信息(Accept Message)

应答者可以决定是接受或拒绝该通信，若拒绝则ICE过程终止，若接受则发送Accept消息。Accept消息的构造过程与Initiate Message类似。

 

7      接受信息处理

接受过程有两种可能。如果Initiate Message的接受者不支持ICE，则Accept Message将只包含缺省的地址信息，这样发起方就知道它不用执行连通性检查了。然而如果本地配置信息要求发起者通过TURN服务器发包来进行连通性检查，这将意味着那些直接发给响应者的包会被对方防火墙丢弃。为解决这个问题，发起者需要重新分配一个TURN来源地址，然后使用Send命令。一旦Send命令被接受，发起者将发送所有的媒体包到TURN服务器，由服务器转发至响应者。如果Accept Message包含候选项，则发起方处理Accept Message的过程就与响应方处理Initiate Message很相似了。

 

8      附加ICE过程

Initiate或Accept消息交换过程结束后，双方可能仍将继续收集传输地址，这通常是由于某些STUN事务过长而未结束引起，另一种可能是由于Initiate/Accept消息交换时提供了新的地址。

 

9      ICE到SIP的映射

使用ICE方式穿透NAT，必须映射ICE定义的参数到SIP消息格式中，同时对其SDP属性进行简单扩展—在SDP的Media块中定义一个新的属性“alt”来支持ICE。它包含一个候选IP地址和端口，SDP的接受端可以用该地址来替换m和c中的地址。Media块中可能会有多个alt属性，这时每个alt应该包括不重复的IP地址和端口。语法属性如下：

      alt-attribute = "alt" ":" id SP qvalue SP derived-from SP                   username SP password SP                  unicast-address SP port [unicast-address SP port]                  ;qvalue from RFC 3261                  ;unicast-address, port from RFC 2327username      = non-ws-stringpassword      = non-ws-stringid            = tokenderived-from  = ":" / id3    

比如:

UE A发的offer中带

m=audio 8076 RTP/AVP 0

a=alt:1 1.0 : user 9kksj== 10.0.1.9 1010

a=alt:2 0.8 : user1 9kksk== 211.35.29.30 9988

a=alt:3 0.4 : user2 9kksl== 218.65.228.110 8076

       其中本地地址的优先级为1.0,STUN地址的优先级为0.8,TURN地址优先级为0.4。当B收到消息后，也进行地址收集，过程和A类似。然后B开始执行连通性检查，可是我们不难发现，到10.0.1.9:1010的STUN请求和到211.35.29.30:9988的STUN请求都将不可避免地失败。因为前者是一个不可路由的保留地址；而后者由于Symmetric NAT会对于每一个STUN/TURN请求都将分配不同的Binding，当数据包抵达A的NAT时，NAT会发现传输地址211.35.29.30:9988已经映射218.65.228.110:3478了。而此时STUN请求的源地址并非218.65.228.110:3478，所以数据包必然会被A的NAT/FW所丢弃。然而，到218.65.228.110:8076的STUN请求却是成功的，因为TURN服务器用它收集到的原始地址来发送TURN请求。

B返回的answer如内

m=audio 8078 RTP/AVP 0

a=alt:4 1.0 : peer as88jl 192.168.1.6 23766

a=alt:5 0.8 : peer1 as88kl 202.205.80.130 10892

a=alt:6 0.4 : peer2 as88ll 218.65.228.110 8078

a=alt:7 0.4 3 peer3 as88ml 218.65.228.110 5556

          当A收到应答后，它也执行连通性检查。和前面一样，对于B的私有地址和STUN来源地址的连通性检查结果均为失败，而到B的TURN来源地址和到B的peer-derived地址成功(本例中它们都具有相同的优先级0.4)。相同优先级下我们通常采用peer-derived地址，所以A发送到B的媒体流将使用218.65.228.110:5556地址，而B到A的媒体流将发送至218.65.228.110:8076地址。

 

 

3GPP中的ICE

3GPP TS 23.228 

IP Multimedia Subsystem (IMS);

Stage 2

G.2.2    ICE and Outbound reference model

Figure G.2a presents the general reference model for IMS access when both the signalling and media traverses NAT devices. Functional elements with dashed lines represent optional functionality. The transport of the Gm signalling is also subject to the policy enforcement.

    P-CSCF内置STUN Server的一部分功能，只处理STUN 协议的Binding-Request消息，这样可进行NAT保活处理。

   主叫UE发起会话前首先收集三类可用媒体面地址：

        1 自己的接口IP地址

        2 NAT/FW设备的外口地址，从STUN Binding-Request的响应中获得

        3 STUN Relay Server的外口地址，从STUN Binding-Request的响应中获得

        一旦这三个地址收集齐备，UE发起INVITE请求，在该请求中的SDP Offer中携带以上三个地址(采用RFC4091定义的anat属性标签)，当呼叫到达被叫时，被叫同样收集被叫侧以上三个地址、端口，并在SDP响应中带回。

          主叫收到SDP Answer后双方进行地址连通性检测，最后选定一对地址、端口作为媒体通信之用。

         为了保证性能最优，终端应按照本地地址->NAT/FW外口地址、Relay Server地址的优先级选择媒体面地址，这样只有对称NAT才需要通过服务器中转。在此过程中，P-CSCF无需参与媒体面的NAT穿越处理。

 

   

 

 

端口预测技术

        无论是TCP还是UDP穿越NAT，穿越成功的关键是获得有效的端口和地址。Cone NAT不需要端口预测，因为这些NAT的分配方式是固定的。大多数Symmetric NAT都以增量a（一般为1或者2）作为下一次分配的端口，因此可以预测下一次分配的端口号。有些Symmetric NAT随机地选择全局端口值，这种情况下端口预测几乎是不可能的，但此种类型的NAT非常少见。端口预测的局限性在于其不适合大型的企业的Symmetric NAT环境。

 

隧道技术

        在防火墙的配置规则较为严格的情况下（如只开放特定的端口），上面几种协议将受到很大的限制，甚至不能使用（如防火墙只开放80端口，只能使用HTTP协议）。最好的方法就是修改防火墙配置（如改成只过滤不请自来的数据包），以支持以上提到的NAT穿越技术的应用。

        另外一种方法是应用隧道技术，对开放了特定端口的防火墙及STUN中定义的4种NAT类型都可以使用。基本的思路是，位于私网内的隧道客户端和位于外网的隧道服务器端通过特定的端口建立连接。私网终端与客户端连接，客户端将终端的数据信息（信令和数据）封装，通过隧道发送到服务器，服务器解封装后将数据信息转发到目的节点。其中，服务器端的功能与TURN服务器的功能类似，但增加了封装和解封装的功能。例如，对采用HTTP隧道技术来说，隧道客户端和服务器端建立了HTTP连接；客户端会将终端的信令消息和所有的数据作为HTTP的净载进行封装，然后传输到服务器端，服务器端解封装之后转发到目的节点。当然，私网节点IP包净载里的源地址信息（如信令里面的IP、端口描述信息）要以服务器分配的地址（即IP和端口号）进行描述，或者由服务器进行改写。

 

P2P应用穿透NAT

        P2P的媒体流直接在各终端间建立，则无法支持Symmetric NAT，但如采用服务器方案2，又失去了P2P的意义。

        如采用服务器方案2，不需要专门维护信令、媒体的relay转发，而是利用公网终端来充当TURN服务器。

        可行的方案是：终端预先发现本端与对端的NAT是什么类型，再做出正确的行为来处理通信（是点到点通信、还是通过服务器转发），这样就增大了算法的复杂度。

    注：中国绝大部分的网络都是cone NAT。如果是个人用户通过宽带、3G上网，也是类似情况。

 

VOIP穿透Http防火墙

      只开通80端口的防火墙时，防火墙只放行目的IP、端口是TCP 80端口的IP包。此时在不为防火墙提供ALG功能的基础上，只能采用Http隧道的方案。

    内网终端首先用http协议连接公网服务器成功后，把通信数据包按Http Post格式封装，发给公网服务器，服务器解出http包中的SIP信令包、RTP媒体包，如对端不在防火墙内，则把SIp、RTP包直接发给对端（也必须先用http连接到公网服务器）。如对端也在防火墙，则用http Get方法把收到的SIP、RTP包封装在内，发给对端。收到对端的响应（Http Post)后转成http Get发给 主叫侧终端。

 

 

VOIP应用如何利用STUN 服务器（Hole Punching 打洞方案）

        在三种Cone NAT中，两种Restricted Cone NAT较常用。

      为了让NAT放行含SIP通信的IP包，必须让终端A、B分别先向对方的公网IP、端口发一个含无用数据的IP包。虽然发出的这个IP包会被对方的NAT网关所拦截。但因为本端NAT网关记录下了本端终端发包的目标IP与端口，则含正式SIP包的IP包可以发送与接收了。

       STUN让SIP终端A可以知道自己的公网IP、端口，但仍无法知道对端B的公网IP、端口（NAT网关一般不会为某个终端固定分配公网IP、端口，否则失去了NAT的意义）。

    所以在STUN实现后，下一个技术点是：如何让SIP终端A知道对端B的公网IP、端口，反之也是。双方都无法主动发包给对方。

 

    一种办法是采用手工方式通知对方。

    可商用的方案是：呼叫通过一个公网服务器中转，虽然这个服务器也可能在内网，但它拥有固定的公网IP、端口，可以直接接受别人发来的IP包（在特定端口上）

    由于公网IP、端口是动态分配，那么在正式开始SIP通信之前，必须让A、B均先向公网服务器发一个IP包，服务器也返回响应IP包。这可视为注册过程。

    这时，服务器上就记录了双方的公网IP、端口，并且双方的NAT网关也会放行服务器发来的IP包

    注册时间如较长的话，服务器会不断发非SIP的Ip包给A、B双方以保活NAT表项，

 

服务器方案分两种：

    服务器方案1：服务器只充当注册之用，呼叫IP包与媒体IP包 直接在A、B间发送。

            A\B可从服务器得到对方的公网IP、端口而发起直接的通信。得到对方信息的过程可使用SIP协议的订阅过程。

            主叫 A通知服务器：我要呼叫B。

            此时根据控制命令的不同，再细分为两种：

            服务器方案1.1： 服务器同时通知A、B双方终端，请双方终端各发一个IP包给对方。

                          A、B间直接的信令面互通、媒体面互通，但双方发出的第一个RTP包会被对方的NAT网关所拦截，RTP包丢失第一个包不影响通话质量，但SIP包正式发送之前，双方必须互相发送一个含无用内容的IP包。

            服务器方案1.2：服务器通知B的终端，请B给A侧发一个IP包。

                         UE A收到这个IP包，就可以发正式的SIP包给B了，此时B侧的NAT网关会放行这个SIP包。同样：第一个RTP包会被对方的NAT网关所拦截。

    注：以UE  B为例，给UE　A的公网地址发一个IP包，会让本侧的NAT网关放行后续收到的A发来的IP包，这称为打洞过程。

 

    服务器方案2(用TRUN协议实现)：所有SIP包、RTP包都经过服务器。

            A直接把SIP包发给服务器，服务器再转发给B的公网IP，B的NAT网关会放行这个SIP包。

           如果信令面与媒体面采用不同地址的话（指服务器面向终端的IP，一般信令面、媒体面由不同服务器处理，所以IP不同），第一个RTP也会被终端侧的NAT网关所拦截。

 

       TURN是通过两方通讯的“中间人”的方式实现穿透，在这种方式下，要进行通讯的两方分别与位于公网上的TURN服务器建立各自的连接进行通讯，由服务器负责在两方之间进行数据转发。要达到这个目的， 实现TURN客户端的终端必须在通讯开始前与TURN服务器进行交互，得到服务器为其临时分配的位于TURN服务器上的公网地址，客户端使用它替换位于应用层中的私网地址。

 

 

注：RTP通信中，不管是哪种服务器方案（不管是服务器中转媒体流量，还是终端间直接用RTP通信），只要信令面与媒体面采用不同地址，则主叫与被叫侧的NAT网关中，总有一个网关收到通信中的第一个RTP包，这第一个RTP包会被接收侧的NAT网关所拦截。另一侧收到第二个RTP包则可被NAT网关所放行。

      但一般认为：丢失第一个RTP包对通话质量影响不大，仅20ms的语音而已。a=ptime 的默认值是20ms。

       另外，因为终端可通过STUN得到当前所处NAT类型，从而可以对第一个RTP包发空包。

 

       有一种情况需要注意，SIP SDP允许通信模式是Sendonly、或recvonly。比如主叫侧是Sendonly，被叫侧是Recvonly。此时主叫侧会向被叫侧发RTP包，被叫侧如果不回RTP包给主叫的话，被叫侧的NAT网关会拦截从主叫侧发来的RTP包。

      目前碰到的SIP终端中，对于本端媒体为Recvonly模式时，都会发空包（或含静音的RTP包）给另一侧。所以上述拦截情况没有发生。

    

 

Symmetric NAT对于VOIP服务器方案的影响

         Symmetric NAT中，即使数据包都从主机UDP端口A发出,但只要目的地址不同,NAT设备就会为之分配不同的出端口B。

        所以在上述提出的公网服务器方案中，服务器记录了双方的公网IP、端口（这时对双方的NAT网关看来，远端是服务器，这个关联关系记录在 NAT绑定表项中）并通知给另一方。

        如采用服务器方案1，双方直接通信的话，此时NAT网关会认为远端改变了，属于新的session，会为本侧终端分配一个新的IP地址、端口，导致通信失败。

       结论： 商用环境下 只能采用STUN服务器方案2  或 TURN 服务器

   

假如有一个clientA，被一个NATA 分隔在在一个子网内，另一个clientB 被一个NATB分隔在一个子网内。两个client 间接通过一个在外网的server，进行通信。

1 当nat 为全双工锥形的时候，我们不需要打洞。

2 当natB 为受限锥形时，clientA 要和clientB 通信，我们要让client B 先打 洞（Hole Punching）。然后clientA才能和clientB 通信。

3 如果natB 为端口受限锥形时，clientB 只要用一个固定端口先打洞。然后再用这个固定端口接收clientA 的通信即可。

4 但是如果NATB 为对称。clientB 先用端口A 先打洞，natB 记住了这个端口。clientA向ClientB 的端口A 通信，但是ClientB 接收时，由于重新分配端口，所以不能接收。因此Stun协议不能解决对称NAT的通信问题。

 

TCP传输对于VOIP服务器方案的影响

         TCP会话的建立是通过一端先发送一个SYN包开始，另一方则回发一个SYN-ACK包的过程。

        对于Cone NAT， 由于NAT网关的session区别了UDP、TCP端口，不同session分配不同公网IP。那么通信双方必须独立 同时地发出一个SYN包到对方的公网地址上，然后各自都单独地返回一个ACK响应来建立一个TCP会话，这个过程被称之为：“Simultaneous open”（“同时开放连接”）

         从本质上说，TCP Hole Punching与UDP Hole Punching并无太大差别。在udp的场景中，终端使用同一个私网地址向另一终端发送消息和等待从另一个终端发来的消息。而由于tcp面向连接的特性，终端必须使用同一个私网地址向另一终端发起连接（connect）和等待连接（listen and accept），事实上，同一个私网地址至少要被使用四次用来建立套接口，包括：与服务器建立的tcp连接套接口，等待来自其他终端的侦听套接口，向另一终端私网地址和公网地址同时发起连接的两个套接口。套接口的这种用法需要使用系统套接口API提供的SO_REUSEADDR特性，要注意的是并不是所有的操作系统都提供这样的特性。

        

        两种方案：

1，上述的STUN服务器方案2  或 TURN 服务器

          SIP终端向服务器注册即可。

2，服务器指导TCP建立过程。