Most of the times you won’t really need to have a look at the content. In fact, while SRTP headers are unencrypted, and so can be inspected no matter how you capture the traffic, the SRTP payloads are not, which means you can’t inspect its contents. This is not an issue when having a look at STUN connectivity checks or a DTLS handshake, but it might be when you want to inspect an RTP or RTCP packet, which will be encrypted as SRTP and SRTCP. Well, the only problem with capturing WebRTC traffic as it is, is that the media content will be encrypted. This kind of activity is especially useful when trying to debug connectivity issues or other WebRTC-related problems: in fact, applications like Wireshark automatically recognize standard protocols like STUN and DTLS, that is the procotols WebRTC PeerConnections are founded upon, and with the right nudge (i.e., if you tell them a specific stream contains them) other protocols like RTP and RTCP too. To the right eye, this is very precious information. Capturing WebRTC traffic looks relatively easy, and most of the times it really is: you just need to launch tools like tcpdump or Wireshark on the machine of one of the peers (or on any machine that is in the media path), and then have a look at the file that has been generated, which most of the times will be a.
0 Comments
Leave a Reply. |