如果你初入WebRTC开发领域，可能会有点沮丧。因为对于问题到底出在哪里你经常摸不着头脑。身边充斥着各色媒体信息，导致你可能不知道到底在哪里遇到了障碍。在这篇博文中，我们将介绍一些能帮助你快速诊断问题，理清思路的工具。
事实上，如果你有超棒的JavaScript SDK工具，就不必担心上述问题了。借助我们的WebRTC平台以及SDK，只需几行JavaScript，你的问题就迎刃而解了。但若你想更深入了解问题或者自力更生的话，就需要正确的工具来协助你处理问题了。
大家最关注的问题之一是媒体是否双向流动。你大可以整天呼吁测试，但压根没有把与会者添加到会话中，又怎么会产生媒体相关问题呢？所以接下来我们会深入探讨解决该问题的正确方法。
WebRTC Internals
现今的浏览器在这方面帮了大忙。我们会着重探讨Chrome浏览器的相关内容（但其实Firefox也有这方面的工具）。WebRTC Internals是Chrome浏览器内部的一个工具，它可以向我们展示WebRTC连接的所有细节。如下图，前往chrome://webrtc-internals/，打开WebRTC Internals。
页面很空？好吧，可能是因为浏览器中没有程序在使用WebRTC。打开一个示例应用，我们看到浏览器中出现了一些信息。如下图，页面出现了一个媒体请求（getUserMedia()），但还没有RTCPeerConnections。如果我们创建一个RTCPeerConnection，通过调用JavaScript SDK中的connect()函数，我们就能看到该页面活跃起来了。需要注意的是，你应该在启动浏览器之前打开WebRTC Internals，它们不会捕捉已经发生的或已开始运行的事情。
现在localhost有一个RTCPeerConnection了，如下图，点击后会看到许多有趣的选项。这里就不展开说明他们了。接下来我们来看看RTCOutboundRTPAudioStream_*区域。如下图末尾所示，当我们展开这个区域时会看到有媒体向外流动。
我们还注意到，RTCInboundRTPAudioStream_*的Stats图没有显示任何内容（稍后会有更详细的解释），但没有一个Inbound数据包这一现象告诉我们，这里只有单向媒体流动。
如果我们启动另一操作，这种情况下也就是创建一个出站PSTN电话呼叫，并将其传输到我们的WebRTC会话，图像中会有一个额外的RTCPeerConnection出现（如下图视频最后所示）。该RTC Peer包含 “RTCInboundRTPAudioStream_*区域的统计图”，向我们展现了一些活跃数据。
你可能已经注意到了，在原始的WebRTC区域，我们永远不会真正看到入站媒体显示，因为它只针对出站流。如果你浏览下图，会看到很多不同的指标，包括数据包丢失、抖动、缓冲区占用率等。如果你有调试质量方面的问题，上述指标对解决该问题很有帮助。但现在，我们先用这个来帮助我们确定媒体是流动的。在下图中我们可以从WebRTC Internals的角度看到整个事件链的展开。本文只是简单讲述了WebRTC Internals的表面。如果你想了解更多，请参阅testRTC的文章。
检查器中的WebSocket流量
WebSockets通常用于发送信令以帮助你发送或接收媒体之前建立WebRTC会话。如果你没有收到媒体，可能需要看看你的初始协商有无问题。这就是websocket检查器可以派上用场的地方。
如果你对 SDK掌握出神入化到能建立连接的地步，你就可以利用内置的检查器查看正在进行的对话。以 Chrome 浏览器为例，我们来看看它是如何发挥作用的。
大多数Web开发人员都很熟悉下图这个界面。但如果你以前没有使用过它，只需要进入View>Developer>Inspect Web Elements即可。我们会访问检查器界面内的网络标签。至于webrtc-internals，你应该在发起请求之前打开它，否则界面中是不会显示它的。在启动建立websocket、开始协商的Javascript调用后，，我们能够在本例中connect()查看来回传递的内容。在该视频中我们能看到，点击条目 ?token=… ，就能显示websocket对话。点击任何一条单独的消息，我们可以看到所有来回传递的内容。
查找错误信息益处多多。比如如果你没有授予适当的权限。你也可以检查你的auth信息是否被正确发送。另外，我们开发的SDP协商行项目对解决你设置的任何约束条件都很有帮助。
相信现在你对这个领域有个更深层次的了解。之后你可以继续深耕、更好地理解你的会话是如何建立的了。
文章地址：https://www.bandwidth.com/blog/debugging-for-webrtc-developers/
原文作者：Adam Covati
