# ODIN IVR-Interactive Solution for Emergency Calls Handling
## 4 Results
### Experimental Evaluation
#### 4.2.2 Effectiveness Evaluation  
In terms of coverage and availability, we evaluate the IVR solution in laboratory environments, and the results indicate the perfect functionality of the system. Taking into consideration that the proposed solution is designed for the Emergency System, it will use the infrastructure of that system, which complies with the specifications. Moreover, we conduct an empirical investigation using 1015 laboratory experimental calls to the IVR solution, of which 235 are related to medical emergencies, 265 are for the police department, 233 are for the fire department, and 282 are related to non-urgent situations. We analyze the responses of the decision tree and compare them with the expected results, as shown in Figure 11. As observed, the obtained results are compliant with the emergency statuses presented in Table 2. The percent of non-urgent situations detected among medical, police, and fire department situations correlates with the number of non-urgent leafs of the decision tree (1 non-urgent leaf from 6 medical emergencies, 3 non-urgent leafs from 10 police emergencies, and 2 non-urgent leafs from 10 fire department emergencies). Therefore, the experimental evaluation indicates the fact that our approach is able to determine both urgent and non-urgent situations, even though the emergency first came from an urgent branch (medical, police, or fire department). On the other hand, the decision tree proves to be a suitable solution; because of its construction, it does not allow the misunderstanding of emergency types.  
\begin{table}
\begin{tabular}{l c c} \hline \hline
**Metric** & **Minimal** & **Evaluated Value** \\ \hline Critical deadline & \textless{}120\(\,\)s & 60\(\,\)s \\ \hline Emergency handling percentage (SLA) & 99.5\% & 100\% \\ \hline Hardware resources—RAM & \textless{}2\(\,\)GB & 1.2\(\,\)GB \\ \hline Hardware resources—CPU & \textless{}70\% & 62\% \\ \hline Round-trip delay & \textless{}100\(\,\)ms & 20\(\,\)ms \\ \hline Loss rate & \textless{}1\% & 0.2–0.3\% \\ \hline Jitter & \textless{}30\(\,\)ms & 1.4\(\,\)s \\ \hline Robustness to unexpected input & 91–93\% & 100\% \\ \hline \hline \end{tabular}
\end{table}
Table 4: Summary of efficiency evaluation.  
Figure 10: Jitter evaluation for caller RTCP packets (green) and called-entity RTCP packets (blue).  
We designed the IVR to take simple text input (DFTM) from the caller and offer audio output. We also implemented text output to the log system. Table 5 presents the obtained results and assesses them against the specifications and requirements from Section 3; the results argue for 100% compliance with the requirements.  
Concerning the ease of use, the IVR proposal uses simple DFTM input with values from 0 to 5. The IVR does not require multiple key press actions or other complex input schemes.  
In addition, we conducted multiple functional testing experiments to assess the functionality and the desired behavior based on the decision tree presented in Table 2. We found that the IVR does not have unexpected behaviors, and it interprets and executes requests as they are given.  
As such, an IVR designed for emergency systems is not required to interact humanly with the caller, but rather to efficiently transfer a caller to the emergency operator. Therefore, the IVR does not implement any functionality that could pass the Turing test.