基于Speex语音引擎的VoIP系统设计与实现
文章摘读：
然而，IP网络的语音传输质量成为制约VoIP发展的瓶颈。基于分组交换的IP网络使得VoIP系统存在分组延迟、延迟抖动、丟包等问题，使得用户听到的话音会出现不连贯甚至中断的现象。现有的VoIP系统还难以实现高质量的实时语音通信。如何提高语音通信质量是近年来VoIP技术研究的一个重要课题。
Speex编码支持多种比特率，如8 kHz采样的低比特率（窄带2．15~24．6 kbps）、16 kHz采样的中比特率（宽带3．95~42．2 kbps）以及32 kHz采样的高比特率（ultra－wideband）。Speex提供了大多数别的编/解码器所不具备的技术性能，主要包括：可以在同一个比特流中对语音信号实现窄带（8 kHz）、宽带（16 kHz）和超宽带（32 kHz）的压缩；支持声音强度的立体声编码；具有丢包补偿能力；具有可变比特率（variable bitrate，VBR）特性，编/解码器可以在任意时刻动态地改变语音的比特率；能实现语音活动检测（voice activity detection，VAD）；能实现声音的DTX（discontinuous transmission，不连续传输），当背景噪声稳定时，可以完全停止声音数据包的传送(例如安静在听被人讲时)；具有语音处理的定点数计算功能（正在开发中）；具有声学回声消除功能。
Speex除了编/解码模块外，还包括噪声消除、静音抑制和自动增益控制等预处理模块以及回声消除模块。正是由于其完备的功能和优良的性能，Speex受到了许多VoIP开发者的关注。2006年9月发布的最新版本Speex 1．2 beta1在声音处理性能上得到了进一步的改善。语音编码和解码的质量有了明显的提高。
在新版本的Speex中，回声消除模块的API有了改进，开发者能更方便地调用这个模块。此外，抖动缓冲区（jitter buffer）模块不再专门针对Speex编码，从而可以应用于其他编码格式的系统。这些特点都为Speex在VoIP系统中的应用奠定了基础。
每个用户首先要通过客户端登录到服务器上，并获取在线好友的列表，然后才能对在线的好友进行语音呼叫。客户端之间的通话采用点对点的方式进行。这就避免了由于语音包经过服务器中转所造成的过大延迟。
++++++++
服务器收到客户端发来的消息时，首先，发回确认信息；然后，建立一个独立线程来处理接收到的数据。在此线程中，按照接收到数据的类别进行相应的处理。
客户端的功能可以分为两部分：一部分是与服务器端进行交互，从服务器上获取相关信息；另一部分是完成不同客户端之间的点对点通话。其中第二部分是VoIP系统的核心。
3点对点通话模型
最基本的VoIP系统应该包含录音模块、放音模块、编码模块、解码模块、接收模块和发送模块。本系统除了这些基本模块之外，还在编码之前增加了Speex的回声消除和预处理模块。
本系统的运行期结构（run－time architecture）由六个线程组成，如图4所示。其中录音线程负责从声卡采集声音数据并将其放到编码缓冲区中等待编码模块使用。编码线程每次从编码缓冲区中取出一帧数据进行Speex的回声消除、预处理以及编码，并将编码后的数据放入发送缓冲区。发送线程每次从发送缓冲区中取出编码后的数据进行打包（RTP包），并且发送给通话的另一方。接收线程负责从网络上接收对方发来的RTP语音包。由于每个RTP包头中有包的序号信息，接收线程依据包的序号把声音数据依次放入抖动缓冲区中，以达到正确排序和消除抖动的目的。解码线程负责从抖动缓冲区中取出接收到的语音数据进行Speex的解码运算，并将解码后的语音数据存入播放缓冲区。播放线程从播放缓冲区中取出语音数据，送至放音设备播放。
上述六线程的运行期结构能够使系统各模块具有高度的并行性。这对于VoIP这种实时性要求很高的应用来说十分重要。例如，当接收线程收到一个包后，它把解码的任务交给解码线程，然后又可以去等待或处理接收其他的数据包。因此对数据包的接收响应较快。
上述通话模型的实现采用了RTP和多方通话机制[5，6]。RTP是由IETF的AVT(Audio Video Transmission)小组开发的，1996年成为RFC正式文档，为IP网上语音、图像、传真等数据等多种需实施传输的媒体数据提供点到点和点到多点的端到端的传输功能。RTP实际上包含两个相关的协议——RTP和RTCP。前者用于传送实时数据；后者实现实时传输控制。RTP本身不提供任何保证实时传送数据和服务质量的能力，而只是提供负荷类型指示、序列号、时戳、数据源标志等信息，接收端根据这些信息重新恢复正确的数据。RTCP是用来提供RTP数据传输质量反馈的，同时可以在会议业务中传送与会者的信息。
在图6所示的多方通话模型中，录音线程每录完一帧后，就把这帧发给编码线程。在编码线程中，对语音帧进行Speex回声消除以及噪声消除、自动增益、静音抑制等预处理，并进行编码；然后将编码后的数据传送给发送线程。在发送线程中，有多个RTP会话；线程调用每个会话的SendPacket()函数，向每个RTP会话方发送语音包。在接收线程中，每个RTP会话从各自的对话方接收语音包放入抖动缓冲区，经过Speex解码运算后，计时器周期性地从每个RTP会话的抖动缓冲区中取出一帧进行混音，然后播放。
RTP的接收反馈RTCP包内包含了近期内发送的数据包的丢失率。接收方在收到RTCP包后，通过丢包率就可以知道对方的接收情况，据此可以采取相应的丢包补偿措施。本系统能够根据丢包率适当地发送一些语音冗余包，保证了语音质量。
目前已有不少VoIP系统在Internet上获得了应用。Skype[7]最具代表性，并且是目前公认最好的商用VoIP系统。IHU[8]和NetTalk[9]则是具有代表性的开源VoIP系统。
在网络互联性能较好的情况下（在CERNET内通信），本系统的通话质量与Skype相比差距不大，只是音质上略逊于Skype。主要原因在于Skype采用了iLBC[10]编码方式，而iLBC的编码后比特率是13．3~15．2 kbps，明显高于Speex在8 kHz采样下的比特率。因此，Skype音质略优于本系统是以占用更多的带宽为代价的。本系统与IHU和NetTalk相比，优势相当明显，主要表现在本系统增加了回声消除和多方通话功能；另外，声音抖动的去除也做得相当好。
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
SRTP协议
由于实时传输协议和可以被用来控制实时传输协议的会话的实时传输控制协议(RTP Control Protocol)有着紧密的联系，安全实时传输协议同样也有一个伴生协议，它被称为安全实时传输控制协议(Secure RTCP或SRTCP)；安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性，就像安全实时传输协议为实时传输协议提供的那些一样。
在使用实时传输协议或实时传输控制协议时，使不使用安全实时传输协议或安全实时传输控制协议是可选的；但即使使用了安全实时传输协议或安全实时传输控制协议，所有它们提供的特性（如加密和认证）也都是可选的，这些特性可以被独立地使用或禁用。唯一的例外是在使用安全实时传输控制协议时，必须要用到其消息认证特性。
为了提供对数据流的保密，需要对数据流进行加密和解密。关于这一点，安全实时传输协议(结合安全实时传输控制协议)只为一种加密算法，即AES制定了使用标准。这种加密算法有两种加密模式，它们能将原始的AES块密文转换成流密文：分段整型计数器模式和f8模式。
除了AES加密算法，安全实时传输协议还允许彻底禁用加密，此时使用的是所谓的“零加密算法”。它可以被认为是安全实时传输协议支持的第二种加密算法，或者说是它所支持的第三种加密模式。事实上，零加密算法并不进行任何加密，也就是说，加密算法把密钥流想像成只包含“0”的流，并原封不动地将输入流复制到输出流。这种模式是所有与安全实时传输协议兼容的系统都必须实现的，因为它可以被用在不需要安全实时传输协议提供保密性保证而只要求它提供其它特性（如认证和消息完整性）的场合。
以上列举的加密算法本身并不能保护消息的完整性，攻击者仍然可以伪造数据——至少可以重放过去传输过的数据。因此，安全实时传输协议标准同时还提供了保护数据完整性以及防止重放的方法。
为了进行消息认证并保护消息的完整性，安全实时传输协议使用了HMAC-SHA1算法。这种算法使用的是默认160位长度的HMAC-SHA1认证密钥。但是它不能抵御重放攻击；重放保护方法建议接收方维护好先前接收到的消息的索引，将它们与每个新接收到的消息进行比对，并只接收那些过去没有被播放过的新消息。这种方法十分依赖于完整性保护的使用(以杜绝针对消息索引的欺骗技术)。
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
网络地址转换(NAT)简介
网络地址转换(NAT,Network Address Translation)属接入广域网(WAN)技术，是一种将私有（保留）地址转化为合法IP地址的转换技术，它被广泛应用于各种类型Internet接入方式和各种类型的网络中。原因很简单，NAT不仅完美地解决了lP地址不足的问题，而且还能够有效地避免来自网络外部的攻击，隐藏并保护网络内部的计算机。
NAT概述
NAT（Network Address Translation，网络地址转换）是将IP 数据报报头中的IP 地址转换为另一个IP 地址的过程。在实际应用中，NAT 主要用于实现私有网络访问公共网络的功能。这种通过使用少量的公有IP 地址代表较多的私有IP 地址的方式，将有助于减缓可用IP 地址空间的枯竭。 [1] 说明： 私有 IP 地址是指内部网络或主机的IP 地址，公有IP 地址是指在因特网上全球唯一的IP 地址。 RFC 1918 为私有网络预留出了三个IP 地址块，如下： A 类：10.0.0.0～10.255.255.255 B 类：172.16.0.0～172.31.255.255 C 类：192.168.0.0～192.168.255.255 上述三个范围内的地址不会在因特网上被分配，因此可以不必向ISP 或注册中心申请而在公司或企业内部自由使用。NAT技术的产生
虽然NAT可以借助于某些 代理服务器来实现，但考虑到运算成本和网络性能，很多时候都是在 路由器上来实现的。 随着接入Internet的计算机数量的不断猛增，IP地址资源也就愈加显得捉襟见肘。事实上，除了中国教育和科研计算机网(CERNET)外，一般用户几乎申请不到整段的C类IP地址。在其他ISP那里，即使是拥有几百台计算机的大型局域网用户，当他们申请IP地址时，所分配的地址也不过只有几个或十几个IP地址。显然，这样少的IP地址根本无法满足网络用户的需求，于是也就产生了NAT技术。NAT技术的作用
借助于NAT，私有(保留)地址的"内部"网络通过路由器发送数据包时，私有地址被转换成合法的IP地址，一个局域网只需使用少量IP地址(甚至是1个)即可实现私有地址网络内所有计算机与Internet的通信需求。 NAT将自动修改IP报文的源IP地址和目的IP地址，Ip地址校验则在NAT处理过程中自动完成。有些应用程序将源IP地址嵌入到IP报文的数据部分中，所以还需要同时对报文进行修改，以匹配IP头中已经修改过的源IP地址。否则，在报文数据都分别嵌入IP地址的应用程序就不能正常工作。NAT技术实现方式
NAT的实现方式有三种，即 静态转换Static Nat、 动态转换Dynamic Nat 和 端口多路复用OverLoad。
受NAT影响的应用程序
一些高层协议（比如FTP，Quake，SIP,VPN）是在IP包的有效数据内发送网络层（第三层）信息的。比如，主动模式的FTP使用单独的端口分别来控制命令传输和数据传输。当请求一个文件传输时， 主机在发送请求的同时也通知对方自己想要在哪个端口接受数据。但是，如果主机是在一个简单的NAT防火墙后发送的请求，那么由于端口的映射将会使对方接收到的信息无效。 一个应用层网关（Application Layer Gateway或ALG）可以修正这个问题。运行在NAT防火墙设备上的ALG软件模块可以更新任何由地址转换而导致无效的信息。显然，ALG需要明白它所要修正的上层协议，所以每个有这种问题的协议都需要有一个单独的ALG。 但是，除FTP外的大多数传统的客户机－服务器协议不需要发送网络层（第三层）信息，也就不需要ALG。 这个问题的另一个可能的解决方法是使用象STUN这样的技术，但是这只针对建立在UDP上的高层协议，并且需要它内建这种技术。这种技术对对称NAT也是无效的。还有一种可能的方案是UPnP，但它需要和NAT设备配合起来使用编辑本段NAT穿透的方法
目前常用的针对UDP的NAT 穿透(NAT Traversal)方法主要有： STUN。 TURN。 ICE。 uPnP等。 其中ICE方式由于其结合合了STUN和TURN的特点，所以使用最为广泛。 针对TCP的NAT 穿透技术目前仍为难点。实用的技术仍然不多。++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
STUN
概述
STUN（ Simple Traversal of User Datagram Protocol through Network Address Translators (NATs)，NAT的UDP简单穿越） 是一种网络协议，它允许位于NAT（或多重NAT）后的客户 端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于 NAT 路由器之后的主机之间建立UDP通信。该协议由RFC 3489定义。方案
一旦客户端得知了Internet端的UDP端口，通信就可以开始了。如果NAT是完全圆锥型的，那么双方中的任何一方都可以发起通信。如果NAT 是受限圆锥型或端口受限圆锥型，双方必须一起开始传输。 需要注意的是，要使用STUN RFC中描述的技术并不一定需要使用STUN协议——还可以另外设计一个协议并把相同的功能集成到运行该协议的服务器上。 SIP之类的协议是 使用UDP分组在Internet上传输音频和/或视频数据的。不幸的是，由于通信的两个末端往往位于NAT之后，因此用传统的方法是无法建立连接的。这 也就是STUN发挥作用的地方。 STUN是一个客户机－服务器协议。一个VoIP电话或软件包可能会包括一个STUN 客户端。这个客户端会向STUN服务器发送请求，之后，服务器就会向STUN客户端报告NAT路由器的公网IP地址以及NAT为允许传入流量传回内网而开 通的端口。以上的响应同时还使得STUN客户端能够确定正在使用的NAT类型——因为不同的NAT类型处理传入的UDP分组的方式是不同的。四种主要类型中有三种是可以使用的：完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT——但大型公司网络中经常采用的对称型 NAT（又称为双向NAT）则不能使用。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TURN（Traversal Using Relay NAT） TURN又称SPAN(Simple Protocol for Augmenting NATs)方式。 TURN协议允许NAT或者 防火墙后面的对象可以通过TCP或者UDP接收到数据。这在使用了对称式的NAT(或者防火墙)的网络中尤其具有实用价值 [1] 。
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ICE
STUN服务器和TURN服务器 你都要有(自己实现或用现成库都行)，然后用ICE统一起来。
这样，能用STUN打通的(大多数情况)，直接P2P不需要中转的就直接通信了。
需要中转的，就是用TURN服务器中转了。
然后即统一，又对各种类型的NAT都可以工作了。
XMPP就是这么做的。
其他商业产品可能不是
1：现在网络上的nat是对称nat多还是非对称nat多？
答：锥形NAT比对称NAT多，而且锥形NAT是趋势，越多的设备支持。
3：像我这种项目可以推荐一种方法？当然不考虑以后升级问题
答：你前面说的前提：用户不多、广域网使用、要穿NAT、要穿防火墙、要TCP，那我建议你直接用HTTP做，通过服务器中转，直接VC的库做，估计你2个星期就能做出来。如果你用STUN、TURN、ICE、UDP、还要在UDP上实现高性能可靠的文件传输，代码都自己写，不知道你几个人做，如果你1个人做，保准你1年时间做不出好效果。
4：如果我要用http隧道技术穿越防火墙，有必要没有必要，我的这个程序只是用一般的用户。
答：用HTTP做吧。如果你真想P2P，那看看我做的组件，看能不能帮你省点事。在这里：www.peergine.com
系列好文1：
NAT and Traversal NAT（TURN/STUN/ICE）
ICE
ICE跟STUN和TURN不一样，ICE不是一种协议，而是一个framework，它整合了STUN和TURN。
系列好文2：
ICE原理（1）
一、ICE产生的背景
基于信令协议的多媒体传输是一个两段式传输。首先，通过信令协议（如SIP）建立一个会话连接，通过该连接，会话双方（Agent）通过SIP交互所承载的SDP消息彼此学习传输媒体时所必须的信息，针对媒体传输机制达成共识。然后，通常采用RTP协议进行媒体传输。
基于传输效率的考虑，通常在完成第一阶段的交互之后，通信双方另外建立一条直接的连接传输媒体。这样就会减少传输时延、降低丢包率并减少开销。这样，用于SIP传输的链路就不再用于传输媒体。现在，问题出现了，由于不采用原来的链路，当传输双方中任一方位于NAT之后，新的传输链接必须考虑NAT穿越问题。
通常有四种形式的NAT，对于每一中NAT方式，都有相应的解决方案。然而，每一种NAT穿越解决方案都局限于穿越对应得NAT方式，对于复杂的网络环境来说，将会出现无法进行媒体传输的情况，同时这些方案给整个系统带来了在不同程度上的脆弱性和复杂性。
在这种背景下，Interactive Connectivity Establishment（交互式连通建立方式）也即ICE解决方案应运而生。ICE方式能够在不增加整个系统的复杂性和脆弱性的情况下，实现对各种形式的NAT进行穿越，使得媒体流在通信双方顺利传输。
二、ICE工作的基本原理及特性
ICE是一种探索和更新式的解决方案。通过收集自己的和通信对端的尽可能多的网络信息（各种网络地址），尝试在这些地址之间建立数据通道，并在此过程中不断更新先前收集到的信息，从而找到和选择一条能够进行NAT穿越的数据通道。
其特性如下：ICE实现不是很复杂，支持TCP穿透，对NAT设备没有要求，支持所有类型的NAT，必须在客户端实现ICE，在网络结构中需要STUN/TURN服务器，具有与协议无关性和良好的可扩展性，安全性和健壮性都比较好。
三、ICE工作的核心
如下内容是ICE实现NAT穿透的所要完成的核心处理。包括收集地址，对地址进行排序、配对，然后执行连通性检查。
1、收集地址
Agent必须确定所有的候选的地址。这些地址包括本地网络接口的地址和由它派生的其他所有地址。本地网络地址包括本地网卡地址、VPN网络地址、MIP网络地址等。派生地址指的是通过本地地址向STUN服务器发送STUN请求获得的网络地址，这些地址分为两类，一类是通过STUN的绑定发现用法得到的地址，称为服务器反向候选地址（Server Reflexive Candidates）或服务器反向地址。另一类是通过中继用法得到的，称为中继地址（RELAYED CANDIDATES）。上面提到的两种用法在相应的规范中提出。
服务器反向地址实际上就是终端的网络包经过一重或多重NAT穿透之后，由STUN服务器观察到的经过NAT转换之后的地址。中继地址是STUN服务器收到STUN请求后，为请求发起方在本机上分配的代理地址，所有被路由到该地址的网络包将会被转发到服务器反向地址，继而穿透NAT发送到终端，因此如名字所示，它是STUN服务器完成中继功能的地址。
为了找到服务器反向地址，Agent通过每一个主机候选地址（通过绑定主机某个接口和端口而获取的候选地址），使用绑定发现用法（Binding Discovery Usage [11]）发送一个STUN绑定请求给STUN服务器（STUN服务器的地址已经配置或者可以通过某种途径学习到）。当Agent发送绑定请求，NAT将分配一个绑定，它映射该服务器反向地址到主机候选地址。这样，通过主机候选地址发送的外发包，将通过NAT转换为通过服务器反向地址发送的包。发往服务器反向候选地址的包，将被NAT转换为发往该主机候选地址的包，并转发给Agent。
当Agent与STUN服务器之间存在多重NAT，那么STUN请求将会针对每一个NAT创建一个绑定，但是，只有最外部的服务器反向地址会被Agent发现。如果Agent不在任何NAT之后，那么，基候选传输地址将与服务器反向地址相同，服务器反向地址可以忽略。
关于中继地址，STUN中继用法允许STUN服务器作为一个媒体中继器进行工作，在L与R之间进行转发。为了发送消息到L，R必须发送消息给媒体中继器，通过媒体中继器转发给L。反之亦然。
从L到R的消息其地址信息将两次被重写：第一次被NAT，第二次被STUN中继服务器。这样，R所了解的想与之通信的地址就是STUN中继服务器的地址。这个地址就是中继地址。
2、连通性检查
Agent L收集到所有的候选地址后，就将它们按优先级高低进行排序，再通过信令信道发送给Agent R。这些候选地址作为SDP请求的属性被传输。当R收到请求，它执行相同的地址收集过程，并且把它自己的候选地址作为响应消息发给请求者。这样，每个Agent都将有一个完整的包含了双方候选地址的列表，然后准备执行连通性检查。
连通性检查的基本原理是：
l 按照优先顺序对候选地址进行排序。
l 利用每个候选地址发送一个检查包。
l 收到另一个Agent的承认检查包。
首先，Agent将本地地址集和远程地址集进行配对，如本地有n个地址，远程有m个地址，那么配成n*m对。对这些地址对进行连通性检查是通过发送和接收STUN请求和响应完成的，此时，Agent在每个地址对的本地地址上，必须同时充当STUN服务器和STUN客户端的角色。若通信双方以某一地址对通过一个完整的四次握手，那么该地址对就是有效地址对。
四次握手是指：当通过地址对中的本地地址向地址对中远程地址发送一个STUN请求，并成功收到STUN响应，称该地址对是可接收的；当地址对中的本地地址收到地址对中远程地址的一个STUN请求，并成功地响应，则称该地址对为可发送的。若一个地址对是可接收的，同时又是可发送的，则称该地址对是有效的，即通过连通性检查。则此地址对可用于媒体传输。
通常在对称NAT的情况下，在地址对验证过程中，会出现发现以前收集地址时没有收集到的地址对，这时就要对这些新的地址对进行连通性检查。
3、对候选地址进行排序
由于收集候选地址时，收集的是所有的候选地址，为了能够更快更好的找到能够正常工作的候选地址对，对所有组合进行排序是势在必行的。在此说明进行排序的两个基本原则，详细地排序算法将在后续文档中描述。
l Agent为它的每个候选地址设置一个数值的优先级，这个优先级连同候选地址对一起发送给通信的对端。
l 综合本地的和远程的候选地址的优先级，计算出候选地址对的优先级，这样，双方的同一个候选地址对的优先级相同。以此排序，则通信双方的排序结果相同。
4、进行SDP编码
为了实现基于ICE的NAT穿越，对SDP进行了扩展，主要增加了四个属性。分别是candidate属性、ice-ufrag属性、ice-pwd属性和remote-candidates属性。
candidate属性为通信提供多种可能的候选地址中的一个。这些地址是使用STUN的端到端的连通性检查为有效的。
remote-candidates属性提供请求者想要应答者在应答中使用的远程候选传输地址标识。
ice-pwd属性提供用于保护STUN连通性检查的密码。
ice-ufrag属性提供在STUN连通性检查中组成用户名的片断。
四、一个例子
两个Agent，L和R，使用ICE。它们都有单个IPv4接口。对于Agent L地址为10.0.1.1，对于R，192.0.2.1。它们都配置了单独的STUN服务器（实际上是同一个），STUN服务器在192.0.2.2地址的3478端口监听STUN请求。这个STUN服务器同时支持绑定发现和中继功能。Agent L位于NAT之后，R位于公网。NAT有一个终端独立的映射特性和依靠地址的过滤特性。NAT公网端的地址是192.0.2.3。网络结构图如下所示。
图一
为了便于理解，传输地址用变量名代替。变量名的格式是entity-type-seqno，其中entity是具有该传输地址的接口所在实体，具体为是L、R、STUN或NAT之一。type不是PUB（地址位于公网）就是PRIV（地址位于内网）。seqno是在实体上的相同类型的各传输地址各自的序列号。每个变量都有一个IP地址和端口号，分别用varname.IP和varname.port表示，varname就是变量名。
STUN服务器有公网的传输层地址STUN-PUB-1（192.0.2.2：3478），绑定发现用法和中继用法都使用这个地址。但在此处，两个Agent都不使用中继用法。
在呼叫过程中，STUN消息有被许多属性注解。“S=”属性表明消息的源传输地址，“D=”属性表明消息的目标传输地址。“MA”属性用于STUN绑定响应消息，指明映射的地址。
基于以上规定，媒体传输的初始过程如下图所示。
消息
双方都对获取的传输地址进行配对，确定优先级并排序。之后，R开始执行其连通性检查（消息9），由于来自L的候选地址是一个私有地址，所以此检查必定失败，而被丢弃。
同时，L收到应答后，除去包含了服务器反向地址的那对检查，只剩一对检查。基于此对地址，执行连通性检查（消息10），经过NAT转换后发送给R（消息11）。R收到之后发送响应给L（消息12），该消息中通过MA属性指明映射地址，经过NAT之后返回给L（消息13），这样L的连通性检查成功。L检查收到的消息13，以NAT-PUB-1为本地地址，R-PUB-1为远程地址创建新的地址对，并添加到有效列表中。
ICE查看有效列表，发现有一对存在，就发送一个更新请求（消息14）给R，这个请求用于删除没有被选中的候选地址，并且指示远程地址。
消息11到达R之后，会触发R执行一个相同地址对的检查，消息16-19反映了这个过程，在收到消息19的响应之后，R会像L一样创建一对新的地址对（以R-PUB-1为本地地址，以NAT-PUB-1为远程地址），并添加到有效列表中。这样就可以进行媒体传输了。
五、总结
本文档从ICE的产生背景入手，讨论了ICE的基本原理及其特性，并对其工作的几个核心部位进行了简单的概述，在此基础之上，分析了一个基于ICE通信的例子。所涉及的内容都是在宏观上的考虑，进一步的详细论述将在后续工作中展开。
1-4 获取服务器反向地址。消息 5 发送一个请求给 R ，该请求包括了本地主机候选地址和服务器反向地址。 R 收到消息 5 之后，通过消息 6-7 获取服务器反向地址（由于 R 不在 NAT 之后，服务器反向地址与主机候选地址相同），然后发送一个应答（消息 8 ）给 L ，应答中包括主机候选地址。至此，通信双方都获取了彼此的网络信息。 ICE 的典型应用环境
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++