Skip to content

Latest commit

 

History

History
58 lines (35 loc) · 2.64 KB

File metadata and controls

58 lines (35 loc) · 2.64 KB

Exercise 2: Traffic Analysis with tshark and Wireshark

Goal

Capture the SIP and RTP traffic generated by DVRTC's background call generators and use it to inspect call signaling and listen to recovered audio.

Prerequisites

  • DVRTC running: ./scripts/compose.sh --scenario pbx2 up -d
  • tshark available in the testing service
  • Wireshark installed on the host machine for packet analysis and RTP playback

Steps

Step 1: Capture SIP and RTP traffic into artifacts/

Run on the host:

./scripts/compose.sh --scenario pbx2 run --rm testing sh

In the testing shell:

tshark -i any -f 'port 5060 or udp portrange 35000-40000' -a duration:120 -w /work/pbx2-traffic.pcap
exit

The current call generators place staggered 20-second calls with no pause, so a 120-second capture gives you several chances to catch a full call with both signaling and media. The capture is written to artifacts/pbx2-traffic.pcap.

Step 2: Open the capture in Wireshark

Run on the host (Wireshark is a desktop application and is not available inside the containers):

wireshark artifacts/pbx2-traffic.pcap

Go to Telephony -> VoIP Calls, select a SIP call, and open Flow Sequence. Use that view to inspect the SIP signaling for the call, including messages such as INVITE, 200 OK, and BYE. Because several call generators are already running, some captured calls may begin mid-call or end after the capture stops. Pick a flow that includes both setup and teardown if you want a complete example.

Step 3: Listen to the captured audio

Run on the host (in Wireshark):

From the same SIP call, inspect the SDP details to identify the media information, then go to Telephony -> RTP -> RTP Streams, select a stream, and use Analyze and Play Streams. You should be able to play audio from one of the captured call-generator calls.

What's happening

DVRTC runs background baresip call-generator instances that continuously place calls to extension 1300. Those calls create SIP signaling on port 5060 and RTP media on the proxied media range, so there is already traffic available to inspect without generating any new calls yourself.

This exercise works because pbx2 allows plaintext SIP and does not require encrypted media for these call flows. An observer with packet capture access can recover call metadata from SIP and, in many cases, play the captured RTP audio directly in Wireshark.

Mitigation

  • Use SIP over TLS so signaling is not exposed in plaintext
  • Enforce SRTP so captured media cannot be played back directly
  • Limit VoIP access to trusted networks or VPNs, especially if SIP-TLS and SRTP is not possible