在 Wireshark 中找到应答 SDP 数据包答案

【问题标题】：Locate answer SDP packet in Wireshark在 Wireshark 中找到应答 SDP 数据包
【发布时间】：2014-12-18 20:43:36
【问题描述】：

我正在跟踪 2 个代理之间的数据包。一个来自 Mac 上的 Chrome，另一个来自 Android 上的 Chrome Beta。他们通过 apprtc.appspot.com 之类的参考网站进行交流，我设法将 some logs 保存在其中。（请下载它或者它只显示为源代码）这样做我还在 Wireshark 中捕获数据包，同时 2 个代理与 WebRTC 通信。

使用过滤器：stun||udp 可以创建大量的绑定请求和响应。

基本上来自rfc doc上面说的：

An agent can respond to an initial offer at any point while gathering candidates...
thus allowing the remote party to also start forming checklists and performing 
connectivity checks.

但是我只是看不到任何 SDP 的迹象，比如相互发送的提议或回答，这可以在上面的 js 日志中找到。为了交叉参考，我希望找到整个通信的正确顺序。

这是Wireshark file kinda of big

【问题讨论】：

SDP 通过您现有的任何信号系统发送。所以，这将是一个发送到信令服务器的数据包（可以是安全的，也可以是不安全的）。
GAE 上的本地代理和信令服务器之间有一些数据包。协议包括 QUIC、TLSv1.2 和 TCP。大多数数据包都是 QUIC。并且从本地到 GAE 服务器出现了一些使用 TLSv1.2 加密的“应用程序数据”。会不会是 SDP 数据？
这可能是 SDP 数据，也可能是 Ice Candidates 以及通过信令服务器交换的任何其他信息。

标签： google-chrome webrtc sdp

【解决方案1】：

Chrome 使用 TLS 加密信令数据包。如果它是直接在对等方之间进行的通信，那么查看信号的唯一方法是查看 chrome 的控制台日志。它应该有SDP的offer answer交换。我假设它使用 SIP 作为信令协议，您应该在控制台中看到它。

如果对等点之间存在中介，例如 FreeSwitch 任何其他 SIP 服务器，则可以更好地调试它，因为它们具有解码和查找使用原始文本消息的密钥。

【讨论】：

从 Chrome 的控制台日志中打印了 offer & answer SDP。我认为在连接检查和完成之前，交换候选人和 SDP 是通过信令服务器进行通信的。对吗？
嗯，就我而言，它使用 Google App Engine Channel API 作为信号协议，因为它只是 apprtc.appspot.com 的克隆。
Chrome 只会在信令服务器连接安全的情况下发送带有 TLS 的数据包（通过 SSL 的 websockets 或类似的东西）。