本文轉載于 RTC 開發者社區?及 WebRTC 中文網

抓取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 復制代碼

停止抓取更簡單，就像你需要一個stop_text2pcap請求來做這件事。

最終，你將會以類似的文本文件結束：

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文件中，而不是將其轉化為文本文件，之后進行處理。這個方法模擬了文本抓取，但是有輕微的不同之處：

就像之前，你使用Admin API開始對Janus中的一個文件進行抓取，但是使用不同的請求

Pcap全局標題在抓取之前就被保存。

所有的輸入輸出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負載描述為前綴的實際媒體流內容。

總結

以上是生活随笔為你收集整理的如何在 Janus 中获取 WebRTC 的流的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。