Decryption issue when using the black_hole feature in SRS to forward RTC streams

[lion117]

Describe the bug

Deciphering WebRTC Data in SRS with Wireshark" (Link to an article on WeChat)

I came across an article shared by Teacher Luo online, which is very useful for analyzing the RTC streaming process.
I attempted to replicate the method described. The actual results were quite different from what was expected. The data forwarding was successful, but the RTP data appeared to still be encrypted.

Version

Module	Version	IP	System
SRS	5.0.b2	192.168.225.103	ubuntu20
METARTCPUSH	7	192.168.225.102	win10
METARTCPLAYER	7	192.168.225.102	win10
WIRESHARK	4.0.5	192.168.225.100

To Reproduce

1. Configure the ./conf/rtc.conf file.
2. Add fields.

rtc_server {
    enabled on;
    listen 8000; # UDP port
    # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#config-candidate
    candidate $CANDIDATE;
    black_hole {
    enabled on;
    addr:192.168.225.100:10000;
    }
}

3. Start the SRS (Simple Real-time Server).

CANDIDATE="192.168.225.103" && ./objs/srs -c ./conf/rtc.conf

Screenshots

wiresharkdata.zip

TRANS_BY_GPT4

[xiaozhihong]

It is not recommended to use Blackhole for forwarding RTC streams, as it will forward not only RTP but also RTCP and DTLS data.

TRANS_BY_GPT4

[winlinvip]

If RTP debugging is being conducted, utilizing Blackhole is acceptable, but it is not recommended for data forwarding purposes.

The reason you are seeing SRTP is due to a display issue with Wireshark. If there are DTLS packets and RTP packets present, Wireshark defaults to identifying these as SRTP packets, even if they are actually RTP packets in reality.

Therefore, you can filter out the RTP packets and then export these RTP packets. By doing so, you will be able to see that Wireshark has correctly parsed them, and it will display them as RTP packets instead of SRTP packets.

TRANS_BY_GPT4

[XueshiQiao]

Clear enough.