What is the key to this article?
The only problem with capturing WebRTC traffic is that the media content will be encrypted. This is not a problem when inspecting STUN connections or DTLS handshakes, but becomes a problem when you want to inspect RTP or RTCP packets, which will be encrypted into SRTP and SRTCP. In fact, although the SRTP header is not encrypted and you can grab traffic in any form, the SRTP payload is not, meaning you cannot view its contents.
In most cases you don't need to view the content. As expected, you can still view the headers of encrypted RTP packets, which is the most commonly used information. However, the same cannot be said for RTCP: in fact, an RTCP message may actually contain more than one packet, and there is not a shared header. Other than that, looking at the RTP payload might work.
This means that it is possible to capture encrypted traffic, but it may be better to capture unencrypted data for diagnostic purposes. Unfortunately, this is not possible without additional help: in practice, browsers often send encrypted data in the case of WebRTC, and even though there are some that allow you to grab unencrypted data for testing, you still need to rely on other tools to get the media flow to do this work
Enter Janus!
As a WebRTC media server, Janus does play its role: in fact, it exists on every media path of the PeerConnection. In addition, since it establishes a security environment for each PeerConnections separately, it can obtain unencrypted RTP and RTCP packets for input and output.
That's what we thought about a year ago, inspired by Firefox, we first added support for text2pcap dump, and the approach we took was straightforward:
1. Use the Admin API to start grabbing information about files processed by Janus. 2. All input and output RTP/RTCP packets are converted into text format and saved in relevant files. 3. After the capture, use the text2pcap App to convert the captured file into a format compatible with Wiresharak or other tools.
The syntax for a request is simple:
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>"
}If you know the relevant session and handle Id, you can easily generate a code to start grabbing the 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/2377476017639045Ultimately, you'll end up with a text file similar to:
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]You can't do much with this file: we see some input and output packets, saved at a certain time, we can also see the payload value in hex, and there is some environment information at the end of each line. You need to pass it to other tools, such as text2pcap, to convert it into a file you can read:
text2pcap -D -n -l 1 -i 17 -u 1000,2000 -t '%H:%M:%S.' /tmp/my-test2pcap-dump.txt /tmp/my-test2pcap-dump.pcapngYou can refer to the manual to learn how to do it and the functions provided by the tool. The above line can basically traverse the text file, convert each packet into pcapng format, and use different IPs and ports for the two parties to communicate, making it easier to distinguish each other.
But shouldn't text serialization be inefficient?
I'm so glad you asked this question!
That's right: while the above method is simple and does its job well, it is CPU intensive. This means that, although it looks good, you cannot use this method in a production environment, because doing so will affect the performance of your machine.
We need another way to save directly to the raw pcap file in Janus instead of converting it to a text file and process it later. This method simulates text fetching, but with slight differences: 1. Like before, you use the Admin API to start a fetch of a file in Janus, but with a different request 2. Pcap global headers are fetched was saved before. 3. All input and output RTP/RTCP packets are saved as files, but first some fake Ethernet/IP/UDP headers are created, and all pcap packet headers are prefixed.
You may have noticed that write processing is not included here: since we save directly to the pcap file, this means that as soon as we stop capturing, the file is generated, exploited, using the appropriate tool. In addition, since text serialization is not required, but written directly to files, this process becomes lightweight, the impact is basically negligible, and it fits well with the media recording feature in Janus.
Even though you saved as a .pcap file using a different method, and named it start_pcap, not start_text2pcap, its syntax is exactly the same as the other: this means you can provide the same information as before, and save it, shortened or not . Looking at the previous example, then, the following is the format of the request:
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/2377476017639045Note that we only changed the request name and the extension of the target file. Everything else is exactly the same.
All of this is scary (I'm too lazy to use curl)
So far, we explained what Jauns provides for scraping unencrypted data, and how to use the Admin API request to take advantage of this feature. Anyway, you probably don't want to do these things manually, or via the command line. Luckily, I have prepared a virtual interface to do these things!
The Janus report brings some ready-to-use network demos, including the Admin API interface. This interface has been covered in detail in the previous article , especially using the information it provides for the purpose of diagnosing problems. We won't repeat the details, but we will focus on how you can start or stop fetching a particular file in Janus. Of course, we assume that you have previously enabled the Admin API backend in the HTTP plugin configuration .
If you have a recent version of the Janus demo, open the Admin API, try navigating through existing sessions, and select a specific handle. You should see a checkbox called Enable fetching before actually processing the information.
Click on it, as follows:
Most settings should be clear and easy to understand, since we covered them when we introduced the Admin API request syntax. The first one allows you to choose the capture type, as mentioned before, or save it directly to pcap, or convert it to a text file and process it later.
Then you are asked to set the path to save the file:
You should only care about the first byte of the packet, not the whole, which will make it efficient to shorten the packet before saving. You can use a shortened select:
When the crawl starts, the page will change the associated checkbox, turning it into a control message, allowing you to pause the crawl in progress at any time.
The current crawling status will also be displayed in the handle information:
Once the grabbing is done, use wireshark whether you need text2pcap or not, and you'll end up with files you can use. Assuming that Wireshark is used, the capture interface is as follows:
As expected, we can see two different IPs (10.1.1.1 and 10.2.2.2) talking to each other on different ports. When Janus grabs traffic, 10.1.1.1:1000 is always the peer's address, and 10.2.2.2:2000 is always Janus' own address.
Of course, Wireshark itself cannot tell whether the contents of these UDP packets are RTP and RTCP information. This is what we need to tell it, to decode traffic information into RTP.
After that, the information displayed by Wireshark will change:
As you can see, Wireshark is responsible for interpreting the RTP header, allowing us to observe and analyze it. The same can be said for the payload, which will be decrypted and seen by us.
A lesser known feature of Wireshark is that it also supports decapsulation of certain media codecs. This means that if you tell Wireshark that a packet contains media encoded in a specific codec, it will give you that specific codec. The VP8 and H.264 codecs are in between, so if the payload type 96 and VP8 are stably associated in the settings, the displayed information will change again:
Although this screenshot is similar to the previous one, there are some key differences: for example, notice how the protocol column is converted from RTP to VP8 for all packets wrapped in type 96. This means that Wireshark is using more advanced decoding and can also observe the payload: in the VP8 case, this means fetching the actual media stream content prefixed with the VP8 payload description. Of course, these are beyond the scope of this article, the only purpose is to show how you should obtain this information: if you want to learn more details of diagnosing such things, you can refer to a great article It was written by Philipp Hancke written.
Author: Shengwang
Original text Grabbing WebRTC traffic in Janus - Nuggets
★The business card at the end of the article can receive audio and video development learning materials for free, including (FFmpeg, webRTC, rtmp, hls, rtsp, ffplay, srs) and audio and video learning roadmaps, etc.
see below!