# 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.1 Results from Normal Mode of Operation  
In this scenario, a video stream is exchanged between two users, and Asterisk is not attacked. Figure 20 represents the traffic that is let through by the Asterisk during normal operation. Only two subscribers are having a video conversation (VM1 and VM2). One video stream is available. Each part of the video stream has a rate of 94 kB/s. As can be seen, the traffic is normal for processing video streams. The result is again from the Asterisk FreePBX dashboard.  
Figure 19: Ping test result during the attack for the voice-call-only study.  
Figure 20: Traffic that proceeded from Asterisk during normal operation—video calls.  
Figure 18: Total number of UDP packets sent during the attack—voice calls only.  
Figure 21 shows the traffic that is let through by the Asterisk FreePBX network interface. As can be seen, the traffic on the Asterisk network interface is the same as in Figure 20, except it is summed.  
Figure 22 represents the traffic that is generated/processed by the VM1. The same traffic is generated/processed by the other VM. As can be seen, if the traffic from the two virtual machines (VM1 and VM2) is summed again, the traffic generated by the two video streams that is processed by the Asterisk FreePBX is obtained.  
Figure 23 presents what the CPU utilization of the Asterisk is for different time intervals for the entire study period. As can be seen from the graph, the CPU utilization is below 30%. In the general case, the load during the calls is hovering around 20%. The results are similar to the results in Section 5.1.1.  
Figure 21: Asterisk’s NIC load during normal operation—video calls.  
Figure 22: Traffic that proceeded/was generated from VM1 during video calls.  
Figure 24 represents what the memory load of the Asterisk was for the entire study period. As can be seen from the graph, the memory load is at 14%, almost the same as the results in Section 5.1.  
Figure 25 shows the summarized information about the parameters of the video stream that is 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 parameters to be monitored are again maximum and mean jitter and packet loss. As can be seen from the figure, the values of these parameters are within the norm. Compared to the same parameters in Figure 7, a slight increase in the individual values is observed, which is normal for real-time video transmission.  
Figure 23: Asterisk’s CPU load during normal operation—video calls.  
Figure 24: Asterisk’s memory load during normal operation—video calls.  
Figure 26 represents how the jitter changes during the entire conversation in the direction from VM1 to the Asterisk and vice versa. Compared to Figure 8, the values are slightly inflated but within the norm.  
Figure 27 represents how the jitter changes during the entire conversation in the direction from VM2 to the Asterisk and vice versa. As can be seen from the graph, the result is similar to the result in Figure 26.  
Figure 26: Jitter variation for the video stream between VM1 and the Asterisk—normal operation.  
Figure 25: Parameters of the video stream between VM_1 and the Asterisk (**a**) and between VM_2 and the Asterisk (**b**) during normal operation.