## 5 Experimentation
The phones on Site A start with a list of thirteen French words to transmit to the Site B phones via their respective protocol. The phones on Site B contain dictionaries with both the English and French words and are used to translate and return the word to the Site A phones. Both sets of phones use an in-built delay of 0.5 s between receiving and sending a message to give a more realistic simulation of voice data while also giving the Webex chatrooms time to catch up between messages. Due to constraints in CPT, actual audio data was unable to be used, however, based on the timestamps and quality of the simulated data, a recreation of what each call may have sounded like was able to be constructed. Once all thirteen words have been transmitted between both phones, the VoIP connection closes, and the date and time are recorded in the 'Data Collection' room in Webex. Recording the start and end time of each call enables efficient and easy gathering of data  
Figure 8: Cisco Webex data collection room. using the Control Centre, which can then be used to measure the effectiveness of the solution proposed in this paper. As well as the set of UDP and TCP VoIP phones, Site A also contains a 'Control Centre' responsible for activating the TCP phones when a DoS attack is detected. The Control Centre (CC) is also used to measure the latency and packet loss of the traffic communicated between the phones on both sites, using the data gathered in the 'Data Collection' Webex room. The CC continuously calculates the latency using the timestamps of the Webex messages output when a phone receives a packet of data, as these are accurate to the millisecond. For every set of data with response times above a set threshold (in this case 0.7), the CC increases the alert level by one. If the alert level reaches a certain value (in this case 5), the network is considered to be under attack, and the UDP VoIP phones are temporarily disabled while the TCP phones are activated. The CC communicates with the TCP and UDP VoIP phones over UDP port 1000 (Note that the protocol and port used here do not affect, nor are affected by, the rest of the experiment as the instructions go directly to the VoIP phones, rather than through one of the gateway routers). The CC continues to monitor the latency of the TCP communication, and once the alert level drops below the set threshold, the option to return to the UDP phones becomes available. If the DoS attack is believed to have ended, the UDP phones can be safely returned to. The value '0.7 s' was selected as the threshold response time to allow for some leeway from times when the network is naturally congested on top of the in-built 0.5 s delay the VoIP phones have between receiving and sending a message. The CC is also used as the main data collection mechanism for the experiment. The CC stores the response times of each call in a list, of which the values are then transferred to a CSV file. The data collection was incorporated into the CC to give more realistic results in the experiment, as a real-life network would gather information in a similar way. The devices used to carry out the UDP flood DoS attack are also CPT 'Things' programmed in Python. Webex was unable to be integrated into these devices as the high rates of packet traffic in conjunction with reading and writing to chatrooms caused CPT to crash, compromising the validity of any results that could have been gathered. Multiple DoS 'Things' were included in the design to test the methodology against a range of scales of attack, from one attacker up to eight. Each device works by selecting a UDP port in a set range, sending a'spam' message to both ROUTER-A1 and ROUTER-A2, incrementing the port number by one, and repeating the message. Each device uses a different range of port numbers in order to put as much stress on the two routers as possible; the first device uses a port range of 1-500, the second uses 501-1000, the third uses 1001-1500, etc.