在Janus中抓取WebRTC流量

本文做者 Janus 项目做者 Lorenzo Miniero，10 月 25 日未来到北京，在 RTC 2019 大会的「WebRTC Workshop」工做坊中分享 WebRTC 服务端开发及 Janus 开发的技巧，并与听众小范围深刻交流，名额有限，如今便可报名：2019.rtcexpo.org/

本文摘要：抓取WebRTC流量看起来相对简单，大多数状况下确实是这样：你只须要在其中一人的机器上安装相似tcpdump或wireshark的抓包工具，而后查看产生的文件，大多数状况会是.pcap或.pcapng文件。这些活动对于诊断链接问题或其它与WebRTC相关的问题颇有用：实际上，wireshark能够自动检测出STUN，DTLS之类的标准协议，这些是WebRTC PeerConnections所关注的。

本文关键是什么？

抓取WebRTC流量的惟一问题就是，媒体内容会被加密。当检查了STUN链接或DTLS握手以后，这不是一个问题，可是当你想要查看RTP或RTCP包的时候，这将会成为一个问题，它将会被加密成SRTP和SRTCP。实际上,尽管SRTP标题没有被加密，你能够任何形式抓取流量，可是SRTP负载不是，意味着你不能查看它的内容。

大多数状况下你不须要查看内容。正如期待的那样，你依然能够查看加密RTP包的标题，也就是最常被用到的信息。无论怎样，对于RTCP并不能这样说：实际上，一条RTCP信息可能实际上包含不止一个包，而且不存在一个共享的标题。除此以外，查看RTP负载可能会有效。

这意味着抓取加密流量是可行的，可是为了诊断目的抓取无加密数据效果可能更好。不幸的是，无其它帮助下这是不可能的：实际上，WebRTC状况下浏览器常常发送加密数据，即便有一些容许你抓取无加密数据进行测试，可是你仍是须要依靠其它工具来获取媒体流，才能进行这项工做。

进入Janus!

做为一个WebRTC媒体服务器，Janus确实发挥了它的效果：实际上，它存在于PeerConnection的每一条媒体路径上。除此以外，因为它为每一个PeerConnections分别创建了安全环境，它能够得到输入和输出的未加密的RTP和RTCP包。

咱们一年前就是这样想的，被Firefox所激励，咱们首先添加了text2pcap dump的支持，采起的方法很直接：

1.使用Admin API,开始抓取Janus处理文件的信息。 2.全部输入输出的RTP/RTCP包都被转化为文本格式，保存到相关文件中。 3.抓取结束后，使用text2pcap App 将抓取文件转化为与Wiresharak或其它工具兼容的格式。

请求的语法很简单：

POST /admin/sessionId/handleId
{
        "janus" : "start_text2pcap",
        "folder" : "<folder to save the dump to; optional, current folder if missing>",
        "filename" : "<filename of the dump; optional, random filename if missing>",
        "truncate" : "<number of bytes to truncate at; optional, won't truncate if 0 or missing>",
        "transaction" : "<random alphanumeric string>",
        "admin_secret" : "<password specified in janus.cfg, if any>"
}
复制代码

若是已知了相关session和handle Id,能够轻易生成一句代码来对handle开始抓取:

curl -X POST -H "Content-Type: application/json" -d '{"janus": "start_text2pcap", "folder": "/tmp", "filename": "my-test2pcap-dump.txt", "transaction": "123", "admin_secret": "janusoverlord"}' http://localhost:7088/admin/8412133783240844/2377476017639045
复制代码

最终，你将会以相似的文本文件结束：

I 18:47:14.126004 000000  80 e0 6c 5d [..] JANUS_TEXT2PCAP_RTP [session=3740061776621518][handle=3149681776118503]
O 18:47:14.128251 000000  80 e0 04 83 [..] JANUS_TEXT2PCAP_RTP [session=3740061776621518][handle=3149681776118503]
I 18:47:14.136577 000000  80 6f 54 8d [..] JANUS_TEXT2PCAP_RTP [session=3740061776621518][handle=3149681776118503]
O 18:47:14.136659 000000  80 6f 03 9f [..] JANUS_TEXT2PCAP_RTP [session=3740061776621518][handle=3149681776118503]
复制代码

你对此文件不能作太多：咱们看到一些输入输出包，在某个时间被保存，还能够看到16进制的负载值，每一行结尾有一些环境信息。你须要把它传给其它工具，例如text2pcap，将它转化为你能够读懂的文件：

text2pcap -D -n -l 1 -i 17 -u 1000,2000 -t '%H:%M:%S.' /tmp/my-test2pcap-dump.txt /tmp/my-test2pcap-dump.pcapng
复制代码

你能够参考说明书详细学习应该怎样作和工具提供的功能，上面的一行基本能够遍历文本文件，将每一个包转化为pcapng格式，使用不一样IP和端口供两方交流，更容易区分彼此。

可是文本序列化不是应该效率低下么？

我很高兴你问了这个问题！

那是对的:尽管上述方法简单易行，而且出色的完成了它的工做，可是耗费了大量的CPU。这意味着，尽管看起来不错，你不能将此方法应用于产品环境中，由于这样作会影响你机器的性能。

咱们须要另一种方法，在Janus中直接保存到原始pcap文件中，而不是将其转化为文本文件，以后进行处理。这个方法模拟了文本抓取，可是有轻微的不一样之处： 1.就像以前，你使用Admin API开始对Janus中的一个文件进行抓取，可是使用不一样的请求 2.Pcap全局标题在抓取以前就被保存。 3.全部的输入输出RTP/RTCP包都被保存为文件，可是首先要创建一些假的以太网/IP/UDP标题，而且都移pcap包标题为前缀。

你可能注意到了这里不包括写入处理：因为咱们直接保存到pcap文件中，这意味着，咱们一中止抓取，文件就立刻被生成，利用，使用适当的工具。除此以外，因为不须要文本序列化，而是直接写入文件，这个过程变得轻量化，影响基本可忽略，而且与Janus中的媒体记录特性很好的契合。

尽管你使用了不一样的方法保存为.pcap文件，并且命名为start_pcap，而不是start_text2pcap，它的语法与另外一个彻底同样：这意味着你能够提供与以前同样的信息，并保存它，不管是否缩短。观察前面的例子，接着，下面是请求的格式：

curl -X POST -H "Content-Type: application/json" -d '{"janus": "start_pcap", "folder": "/tmp", "filename": "my-pcap-dump.pcap", "transaction": "123", "admin_secret": "janusoverlord"}' http://localhost:7088/admin/8412133783240844/2377476017639045
复制代码

注意，咱们只改变了请求名称和目标文件的扩展名。其它彻底同样。

全部这些都令人惧怕（我太懒了，不想使用curl）

目前为止，咱们解释了Jauns对于抓取未加密数据所提供的功能，如何使用Admin API请求利用这个特性。无论怎样，你可能不想手动作这些事，或经过命令行。幸运的是，我准备了一个虚拟接口来作这些事！

Janus报告带来一些可供使用的网络演示，包括了Admin API接口。这个接口在以前的文章中已经详细介绍过，特别是使用它提供的信息达到诊断问题的目的。咱们不会重复这些细节，可是咱们会关注一点，你应该如何在Janus中开始或中止抓取一个特定文件。固然了，咱们假定了你以前在HTTP插件配置中开启了Admin API后端。

若是你有Janus演示的最近的版本，打开Admin API,尝试导航现有session，选择一个特定的handle。你应该在实际处理信息前看到一个叫作开启抓取的勾选框。

点击它，以下：

大多数设置应该清晰易懂，由于当介绍Admin API请求语法时，咱们介绍了它们。第一个容许你选择抓取类型，以前讲到过，或者是直接保存到pcap，或者是转化为文本文件以后处理。

接着你被要求设置保存文件的路径：

你应该只关心包的第一个byte，而不是所有，这将会使在保存以前缩短包变得有效。你可使用缩短选择：

当抓取开始时，网页将会改变相关的勾选框，将其转化为控制信息，让你随时能够暂停正在进行的抓取。

当前的抓取状态也会显示在handle信息中：

一旦抓取完成，不论是否须要text2pcap，使用wireshark，最终你会获得你可使用的文件。假设使用了Wireshark,抓取界面以下所示：

正如期待，咱们能够看到两个不一样的IP（10.1.1.1和10.2.2.2）在不一样端口相互交流。当Janus抓取流量时，10.1.1.1:1000老是peer的地址，10.2.2.2:2000老是Janus本身的地址。

固然，Wireshark本身并不能分辨这些UDP包的内容是RTP和RTCP信息。这是咱们须要告诉它的，将流量信息解码为RTP。

以后，Wireshark显示的信息会变化：

如你所见，Wireshark负责解释RTP标题，使咱们能够观察和分析它。对于负载也能够这样说，它将会被解密，而且被咱们看到。

Wireshark一个不多被人知道的特性，是它也支持对某些媒体编解码器的解封装。这意味着，若是你告诉Wireshark一个包内含有特定编解码器编码的媒体信息，它将会给你一个具体的编解码信息。VP8和H.264编解码器处于其中，所以，若是在设置中将负载类型96和VP8稳定关联起来，显示的信息将会再一次改变：

尽管这张截图与以前的类似，仍是存在一些关键区别:例如， 注意对于敷在类型96的全部包，协议一列如何从RTP转化为VP8。这意味着Wireshark正在使用更高级的解码，也能够观察负载：在VP8状况下，这意味着获取以VP8负载描述为前缀的实际媒体流内容。固然，这些超出了本文的范围，惟一的做用是展现你应该如何获取这些信息：若是你想要学习诊断此类内容的更多细节，你能够参考一篇很棒的文章，它是由Philipp Hancke写的。