# Studying the Impact of a UDP DoS Attack on the Parameters of VoIP Voice and Video Streams
## 5 Results
### Results When Only Video Traffic Is Exchanged
#### 5.2.2 Results When Asterisk Is Attacked  
In this scenario, two subscribers in the network are having a video conversation with each other, and while they are talking, the Asterisk is attacked/flooded with UDP packets--a UDP DoS attack.  
Figure 28 represents what traffic is let through by the Asterisk during the attack. As can be seen from the graph, the received traffic (RX) is again around 12 MB/s. The transmitted traffic remains the same as during the normal operation mode. This figure shows that Asterisk is flooded--a successful UDP DoS attack.  
Figure 29 shows what traffic is let through by the Asterisk network interface. The presented result confirms the result of the Asterisk network interface monitoring tool--the server is flooded with UDP packets.  
Figure 28: Traffic that proceeded from Asterisk during the attack—video calls.  
Figure 27: Jitter variation for the video stream between VM2 and the Asterisk—normal operation.  
Figure 30 shows what the load on the Asterisk network adapter was during the attack. As can be seen from the graph, the load is about 10%. The result is the same as the result in Section 5.1.2.  
Figure 31 represents what the CPU load of the Asterisk was at the end of the study. The graph is an extension of the results in Section 5.2.1. There is one peak that exceeds 50% load because that is when the UDP DoS attack starts. After that, the load decreases, and it settles in a stable range. Compared to the normal mode of operation (Section 5.2.1), a slight increase in load is observed for all three measurement time periods, but it is not anything dramatic.  
Figure 32 represents what the Asterisk memory load was at the end of the study. The graph presented is again a continuation of the same graph in Figure 24 because the study was conducted on the same day. As can be seen from the graph, there is a slight 1% decrease in memory load at that particular time. The other values are close to the same results presented in Sections 5.1 and 5.2.2.  
Figure 30: Utilization of the Asterisk’s NIC during the attack—video calls.  
Figure 29: Asterisk’s NIC load during the attack—video calls.  
Figure 33 presents the summarized information about the parameters of the video streams that are exchanged between VM1 (192.168.2.3) and VM2 (192.168.2.6) in both directions--from VM1 to the Asterisk (192.168.2.2), then from Asterisk to the VM2 and vice versa. The presence of packet loss is noticed which is minimal. The rest of the parameters are within normal limits.  
Figure 34 represents how the jitter changes during the entire conversation in the direction from VM1 to the Asterisk and vice versa. As can be seen from the graph in the  
Figure 31: Asterisk’s CPU load during the attack—video calls.  
Figure 32: Asterisk’s memory load during the attack—video calls.  
direction from VM1 to the Asterisk, there is not any striking difference with the result obtained in the normal mode of operation--Figure 26.  
Figure 35 represents how the jitter changes during the entire video call in the direction from VM2 to the Asterisk and vice versa. As can be seen from the graph, the result is the same as in Figure 34.  
Figure 36 shows how many UDP packets were sent during the attack. During the attack, 32,044,426 UDP packets with a size of 950 bytes were sent.  
The VoIP server is still available and accessible. This can be seen/confirmed from both the screenshots presented from the Asterisk dashboard menu and the result of the ping command executed by VM1--Figure 37. The result is for the entire period of the study. As can be seen from the result, again, there were no packet l  
Figure 34: Jitter variation for the video stream between VM1 and the Asterisk during the attack.  
Figure 35: Jitter variation for the video stream between VM2 and the Asterisk during the attack.  
were processed by the Asterisk, and the server responded to all regardless of the UDP DoS attack.