作者：Lee Sylvester（原文链接）
翻译：刘通
原标题：WebRTC Issues and How to Debug Them
前文链接：WebRTC的问题以及如何debug-1
WebRTC debug从何处入手
有几种调试WebRTC应用的方法，也有一些你需要的重要工具。我们在这里将介绍最重要的工具，同时介绍大多数刚从事WebRTC的开发人员经常遇到的典型问题场景。
然而，在我们太详细讨论之前，先来看看典型的WebRTC连接过程。
WebRTC连接过程
所有WebRTC连接都需要来自信令协议的一点帮助。这只是需要引入第三方通信协议以允许在主叫方和被叫方之间交换数据的高端说法。
这些数据包括了有关每台机器的浏览器音频和视频功能的信息，以及有关连接到的网络的一些信息。此信息用于配置WebRTC连接选项和流类型。
这种信息共享的典型技术包括COMET和Web Sockets。但是你可以选择使用任何技术。
使用信令技术，以及两台互相连接的用户机，你就可以开始启动WebRTC连接过程了。
提议及应答
WebRTC连接通过使用提议及应答进行初始化。从客观角度看：
# 客户端向对等端发送一个连接提议。
# 对等端收到要连接的提议。
# 对等端发送给客户端一个应答。
# 客户端接收到对等端的应答。
这一切更像是我们日常生活的理解。我的意思是，谁会希望在接受提议之前就开启了浏览器通话呢？
但实际上要比这更复杂。
1. 在发送连接提议之前，客户端会创建一个RTCPeerConnection对象的实例，并使用以下命令生成SDP数据包：rtcPeerConnection.createOffer()。这会将客户的机器和浏览器的功能细化。
2. 然后通过RTCPeerConnection对象的setLocalDescription方法将SDP数据包设置为客户端的本地描述。
3. 然后将SDP数据包发送给对等端，对等端通过其RTCPeerConnection对象实例的setRemoteDescription方法将其设置为远程描述。
4. 对等端然后使用RTCPeerConnection对象的createAnswer方法生成自己的SDP数据包，并将其设置为其本地描述。
5. 对等端将SDP数据包作为应答响应发送给客户端，并将其设置为其远程描述。
这个时候，客户端和对等端就都知道对方的会话能力了。
连接性
为了创建连接，WebRTC使用所谓的STUN（Session Traversal Utilities for NAT）和TURN（Traversal Using Relay around NAT）。
这些听起来相当复杂，但实际上是非常简单的协议，旨在创建两个候选之间的连接。
STUN服务器
第一个要说的是STUN。当机器希望公布自己的连接性时，它们需要通知连接器自己的公共IP地址。毕竟，典型用户计算机通常没有自己的公共域名。
但问题是，机器的本地网络地址与公共网络地址有很大的不同。这是NAT的一部分，用于将传入和传出数据包的IP地址转换为本地和公共IP地址。
为了解决这个问题，用户的机器向STUN服务器发出请求。当请求数据包通过本地NAT时，数据包报头中的本地IP地址会被转换为公共IP地址。
然后，STUN服务器会接收到这个数据包，将其报头中的公共IP地址复制到它的主体中，然后将其发回给发送者。然后数据包通过用户的NAT，从而将报头IP转换回本地IP地址。
由于数据包主体保持不动，机器现在能够识别其公共IP，并将其发送给希望建立连接的对等端。
TURN服务器
TURN服务器是作为STUN协议的扩展而构建的。使用相同的报头结构，但是提供了额外的功能，被称为commands。
TURN服务器作为代理服务器被使用。客户端使用allocation（分配）建立到对等端的安全连接。此分配只是对等端可以连接到的服务器上的协商UDP端口，用于侦听来自客户端的流量。一旦在服务器上建立了客户端和对等端之间的连接，数据就可以通过两种的方式进行自由传递。
TURN服务器的设计方式使客户端有更多的权力和机会发送数据，而并非对等端。处于这个原因，并且取决于本地网络配置，客户端/对等端连接可能比其他方式更为成功。
