在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寫的。