WebRTC支持P2P，但是仍需要Server：
- 协调通讯过程中，Client之间需要交换Meta Data
- 需要处理NAT或FW
什么是信令
信令就是协调通讯的过程，为了建立一个WebRTC的通讯过程，客户端需要交换如下信息：
- Session，用来开始和结束通话
- 处理错误的消息
- Meta Data，如各自的音视频解码方式、带宽
- 网络数据，如对方的公网IP、端口、内网IP及端口
信令处理过程需要Client能够来回传递消息，这个过程WebRTC没有实现，需要自己创建。
TURN和STUN
Meta Data是通过信令服务器中转发给Client，但是对于流媒体数据，一旦会话建立，首先尝试使用P2P连接。
WebRTC通过ICE框架来处理复杂的网络环境
- ICE试着找最好的路径来让Client建立连接，尝试所有可能的选项，选择最优的方案
- ICE首先尝试P2P连接，如果失败就会通过TURN服务器进行转发
换一个说法： - STUN服务器是用来取外网地址的
- TURN服务器是在P2P失败时进行转发的
STUN和TURN服务的主要作用是处理打洞和转发，配合完成ICE协议
首先尝试使用P2P，如果失败将求助于TCP，使用TURN转发两个端点的音视频数据，TURN转发的是两个端点之间的音视频数据不是信令数据。因为TURN服务器是在公网上，所以他能被各个客户端找到，另外TURN服务器转发的是数据流，很占用带宽和资源。
ICE技术
基于IP的语音、数据、视频等业务在NGN（Next Generation Network）网络中所面临的一个实际困难就是如何有效地穿透各种NAT/FW的问题。对此，SIP（会话初始化协议）以往的解决方法由ALGs（(Application Layer Gateway Service)）、STUN、TURN等方式。
现在有一种新的媒体会话信令穿透NAT/FW的解决方案-交互式连通建立方式ICE。它通过综合利用现有协议，以一种更有效的方式来组织会话建立过程，使之在不增加任何延迟同时比STUN等单一协议更具有健壮性、灵活性。多媒体会话信令协议是在准备建立媒体流传输的代理之间交互信息的协议，例如SIP、RTSP（real time streaming protocol）等。
媒体流与信令流截然不同，它们所采用的网络通道也不一致。由于协议自身设计上的原因，使得媒体流无法直接穿透网络地址转换/防火墙(NAT/FW)。因为它们生存期的目标只是为了建立一个在信息中携带IP地址的分组流，这在遇到NAT/FW 时会带来许多问题。而且这些协议的目标是通过建立P2P(Peer to Peer)媒体流以减小时延，而协议本身很多方面却与NAT存在兼容性问题，
这也是穿透 NAT/FW的困难所在。
ICE简介
交互式连通建立方式ICE(Interactive Connectivity Establishment)并非一种新的协议，它不需要对STUN、TURN或RSIP进行扩展就可适用于各种NAT。
ICE是通过综合运用上面某几种协议，使之在最适合的情况下工作，以弥补单独使用其中任何一种所带来的固有缺陷。对于SIP来说，ICE只需要定义一些SDP(Session Description Protocol)附加属性即可，对于别的多媒体信令协议也需要制定一些相应的机制来实现。
流程
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 Message由一系列媒体流组成，每个媒体流都有一个缺省地址和候选地址列表。
缺省地址通常被Initiate Message映射到SIP信令消息传递地址上，而候选地址列表用于提供一些额外的地址。
对于每个媒体流来说，任意Peer之间实现最大连通可能性的传输地址是由公网上转发服务器(如TURN)提供的地址，
通常这也是优先级最低的传输地址。
客户端将可用的传输地址编成一个候选地址列表(包括一个缺省地址)，并且为每个候选元素分配一个会话中唯一的标识符。
该标识符以及上述的优先级都被编码在候选元素的id属性中。一旦初始化信息生成后即可被发送。
5. 响应处理：连通性检查和地址收集
会话应答方接收到Initiate Message后，会同时做几个事情：
首先执行收集传输地址中描述的地址收集过程。这些地址可以在呼叫到达前预收集，这样可以避免增加呼叫建立的时间。
当获得来源地址以后，应答方会发送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. Accept Message的处理
Accept过程有两种可能。如果Initiate Message的接受者不支持ICE，则Accept Message将只包含缺省的地址信息，这样发起方就知道它不用执行连通性检查了。然而如果本地配置信息要求发起者通过TURN服务器发包来进行连通性检查，这将意味着那些直接发给响应者的包会被对方防火墙丢弃。为解决这个问题，发起者需要重新分配一个TURN来源地址，然后使用Send命令。一旦Send命令被Accept，发起者将发送所有的媒体包到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地址和端口。
总结
ICE方式的优势是显而易见的，它消除了现有的UNSAF机制的许多脆弱性。例如，传统的STUN有几个脆弱点：
- 一个是发现过程需要客户端自己去判断所在NAT类型，这实际上不是一个可取的做法。而应用ICE之后，这个发现过程已经不需要了。
- 另一点脆弱性在于STUN、TURN等机制都完全依赖于一个附加的服务器， 而ICE利用服务器分配单边地址的同时，还允许客户端直接相连，因此即使STUN或TRUN服务器中有任何一个失败了，ICE方式仍可让呼叫过程继续下去。
- 此外，传统的STUN最大的缺陷在于它不能保证在所有网络拓扑结构中都正常工作，最典型的问题就是Symmetric NAT。对于TURN或类似转发方式工作的协议来说，由于服务器的负担过重，很容易出现丢包或者延迟情况。 而ICE方式正好提供了一种负载均衡的解决方案，它将转发服务作为优先级最低的服务，从而在最大程度上保证了服务的可靠性和灵活性。
- 此外，ICE的优势还在于对
Ipv6的支持，目前Cisco等公司正在设计基于ICE方式的NAT/FW解决方案。
网友评论