Speech transmission via the IP protocol poses various challenges in corporate networks and the provider environment. First, there is a very high availability requirement. As a real-time service, users also immediately notice problems in the quality of service. Network quality parameters such as packet loss, jitter, and delay significantly impact the resulting voice quality over the Real-time Transport Protocol (RTP).
Note that one differentiates between different data streams in the VoIP environment. The signaling represents the first data stream. Signaling is the communication for setting up and clearing downstreams and changes to them. This is usually done in today's VoIP networks using the Session Initiation Protocol (SIP). The second data stream is the transmission of speech. In the event of an error, it is therefore necessary to be able to record both data streams and analyze them efficiently.
The following example gives a step-by-step overview of how reduced VoIP quality can be analyzed with the Profitap IOTA. It concerns errors in call setup as well as voice quality errors.
The first step is to configure the physical interface. To do this, we navigate to the Capture page using the left menu tree, and then to the Interface Configuration section. The interface is configured as SPAN (out-of-band) with 10/100/1000 Mbit/s Auto-Negotiation as shown below, meaning both physical interfaces can receive the traffic to be analyzed from a SPAN port or a TAP. If the IOTA is to be integrated in-line into the data stream, the checkbox next to Inline Mode must be ticked and the Save button clicked.
Figure 1: Physical interface configuration. In this case, 10/100/1000 Mbit/s Auto-Negotiation in SPAN mode.
After we have prepared the physical interface and positioned the IOTA, we connect to the appropriate cable and start the capture process on the Capture Control page by clicking the Start Capture button at the bottom of the page. Alternatively, we can start the capture process by pressing the physical Start Capture button on the IOTA device. This speeds up the process and can be done by untrained or non-privileged persons.
Figure 2: Start the recording using the “Start Capture” button in the “Capture Control” submenu.
To troubleshoot VoIP calls, we will first use the VoIP dashboard.
Figure 3: Navigate to VoIP Dashboard.
On the VoIP dashboard, we get a list of VoIP sessions. Here, we can see the source and target URI, user agent, and session duration. Use the Select column in the VoIP sessions table to filter for a specific session, as in our example in Figure 4 where we filtered for the session related to “sip:23@192.168.178.1;user=phone”.
After applying the filter for the desired VoIP session, we get the VoIP flow diagram on the right-hand edge, which can be used to get a general idea of the endpoints involved in the VoIP session. In addition, a filter is then set to the VoIP Call ID in the upper area. Consequently, all panels in the lower area of the dashboard are filtered to this call.
Figure 4: VoIP dashboard with SIP session from number *29 to number 23.
Further down on this dashboard, you can see the quality parameters of packet loss and jitter in relation to the Real-time Transport Protocol over which the voice is transmitted. High jitter leads to robotic voices, and packet loss leads to conversational silence. Figure 5 shows high packet loss and jitter rate at times within the VoIP session. We can also see the direction of the resulting jitter and packet loss. In the example, this was due to a poor WiFi connection of the softphone used.
Figure 5: RTP jitter and packet loss in the VoIP dashboard.
This dashboard also enables a view of the so-called mean opinion score (MOS), i.e., the subjective call quality for the user depending on the direction of communication. An example is included in Figure 6. However, this also depends on the codec used. The frequently-used codec G.711 achieves a maximum MOS of approximately 4.4.
Figure 6: Calculated MOS graph in the VoIP dashboard.
Based on the filter on the VoIP call ID, information about the corresponding voice data stream (RTP streams) is also displayed, as shown in Figure 7. In addition to client and server IP and port, we can see the call duration. Additionally, a PCAPNG file containing the RTP stream can be downloaded. For example, we can listen to the voice data in Wireshark with supported codecs and hear any errors in the voice transmission. If a user reports noise during a phone call, a potential error in the network can be checked quickly and easily.
Figure 7: Listing of the RTP streams in the VoIP dashboard.
In addition to evaluations of poor voice quality, there may also be errors in signaling, such as call setup or teardown. To evaluate these for an individual call, we select the desired call in the VoIP sessions, as mentioned above. Then we can see the responses to the SIP requests in the SIP Response Type section. If there are many messages with 4xx (client-side errors), 5xx (server-side errors), or 6xx (global errors), these should be analyzed more closely.
Figure 8: SIP response type graphic with numbers of the respective response types.
However, caution is advised with 4xx in particular since, if authentication is used for SIP, 407 and 401 messages on registrations and invites are perfectly normal. To be able to see the exact answer and also the time in the course of the call, we have the SIP Flow Details evaluation in the VoIP dashboard. In the right pane, a SIP Flow Diagram shows the call flow. In this case, we can see that authentication was used but received response 407, in these contexts the 4xx responses were normal and not an error.
Figure 9: SIP Flow Details with detailed call signaling flow.
If performance problems occur when the call is set up, it is advisable to download the VoIP call from the VoIP Sessions table above as a PCAPNG. This way, a large delay in the responses to SIP requests could be found to be the cause of the performance issue.
VoIP troubleshooting processes are often like looking for a needle in a haystack. Profitap IOTA offers a simplified search for the root cause through easy-to-use filter options, such as selecting individual calls.
Signaling errors can be detected based on the SIP flow diagram and downloaded as PCAPNG for a deeper analysis, for example, to view individual headers.
The RTP Jitter and Loss graphics provide a good overview of the voice quality. In the RTP streams, the IOTA also offers the option of downloading a PCAPNG with the RTP data to listen to the voice data in the RTP player in Wireshark, for example.
Read more IOTA workflows and use cases on our Knowledge Base