SIP/RTP analysis in heterogeneous networks

The September issue of LANLine magazine focuses on sources of error that arise through the integration of Voice over IP (VoIP) into the networks and how the relocation of voice applications into the cloud affect us. Managing Director Klaus Degner of Allegro Packets GmbH describes the associated requirements for the analysis and monitoring functions. The "Client" and "Server" endpoints can be tested with simple methods. The IT department is helped by current network analysis tools in the area of SIP/RTP analysis in the company network.

SIP and RTP are currently the most widespread protocols for voice and video transmission and represent two of the most frequently used protocols in the LAN/WAN environment. VoIP telephony means new requirements for the administrator with regard to quality assurance in the network.

The two protocols SIP and RTP are two of the basic elements of VoIP communication. While the SIP (Session Initiation Protocol) is responsible for setting up communication sessions, the actual voice data is transmitted via the data protocol RTP (Real-Time Transport Protocol). The two protocols have won the race as successors of circuit-switched networks and have prevailed against H.323 and SCCP. Conversely, SIP and RTP are two of the critical protocols in networks in addition to HTTP(S) and DNS.

SIP cloud telephone systems offer the extra advantage that they can be used to make calls outside the organisation without complicated forwarding mechanisms. Dedicated telephones and lines are now being replaced by PC software or smartphone apps, enabling telephone calls to co-exist with other network traffic. Accordingly, for IT departments this means setting new standards for the quality of WLAN, LAN and WAN connections in the enterprise.

SIP, more especially RTP, inherit all the characteristics of packet-switched networks but can suffer from challenges which did not exist in the circuit-switched telephone networks. Issues such as packet loss or jitter did not exist in the original voice-based networks. In contrast, Ethernet is a best-effort network that transmits voice and other data in a more efficient manner. Data latency and packet losses can and do occur. The network layers have to correct this themselves.

In practice, SIP telephony often confronts IT departments with frequent error messages: The quality was poor, there was an echo, a crack, noise, latency or a disconnect in the connection. Many users suspect a network problem behind the poor connection. Often these errors occur only sporadically, so they are difficult to reproduce. So how can an IT employee deal with user complaints and quickly fix the problem?

 

Sources of Error

There are basically four different sources of error for every VoIP application: the VoIP client, the VoIP server, the network between client and server, and the connection or network between the VoIP server and a second subscriber.

The possible error sources ‘client’ and ‘server’ can be tested easily compared to the network. Systematic errors such as a bad microphone can be tested by cross-comparisons. Alternatively, conventional network analysis tools offer the possibility of retrospectively playing the RTP stream as audio. Errors that occur on the server or client side in front of the network - be it a crackle or noise or a quiet microphone, etc. - often appear at this point.

Finding errors within the network is more complicated. First of all, it is important to understand how an audio codec works via RTP. Most audio codecs break down the audio data into blocks of 20 or 30 ms and package them in RTP. This ensures a constant RTP packet rate to and from the client. However, the client or server does not receive the data constantly every 20 ms, but with a deviation, classed as jitter.

The endpoint then determines the largest jitter and adjusts the audio buffer to keep the waiting time as short as possible. If this jitter increases or decreases over time, the codec attempts to adapt to it. Either a pause occurs in the audio buffer or part of the buffer is removed. In a real conversation, this sounds as if the person you are talking to is not pronouncing the words completely. So if there are sporadic peak loads in the network, this leads to a fluctuating jitter and a loss of quality in RTP. This type of network error can be investigated using network analysers. A burst analysis can show all load peaks and their causes in real-time.

Another reason for poor quality can be caused by latency between two endpoints. The greater the latency, the longer the caller has to wait for an answer. The latency can be high, especially in WLANs, so the connection is perceived as bad. Packet loss on the other hand, leads directly to dropouts in the voice. These factors can also be measured with smart network analysis tools.

 

Influences on Voice Traffic

The question of what actually causes network problems with SIP/RTP is open. Experience shows that the cause is often not to be found in SIP/RTP, but rather in other, often parallel network traffic.

This is illustrated by a practical example: Sales department staff in a company experienced frequent quality problems with VoIP via their cloud SIP provider. After some research it became apparent that the problems always occurred around eleven o'clock, both on Windows PCs and on smartphones via the WLAN. However, the IT department was unable to detect any malfunctions. Neither the telephony nor the uplink to the Internet showed any problems.

The analysis of network traffic with an up-to-the-minute  troubleshooting tool provided the solution: the cause was the incorrect configuration of WSUS (Windows Server Update Services), which ran at eleven o'clock in the morning instead of in the night. The updates caused so much traffic and load that both the LAN and the WLAN generated jitter of up to 500 milliseconds and packet losses of about five percent. After the administrators had set the WSUS server to eleven o'clock at night, the problem was solved.

 

Limit VoIP Quality Losses

In addition, it is sometimes advisable to perform a virtual or physical separation of the VoIP circuits from the rest of the network so the VoIP lines are not affected by other traffic. When VoIP telephony is carried out via mobile phones and client PCs, segmentation is more difficult because it is not possible to separate VoIP and non-VoIP devices. An example of this is automatic updates on Android or ioS devices. Some of these devices download several GBytes with high bandwidth over a WLAN, often completely unplanned, which can negatively affect the quality of a running call.

Backups are often underestimated as a load source. PCs and especially notebooks can deliver backups at speeds well over 100 MBit/s thanks to to SSD hard disks. As a result, notebooks with SSD and 802.11ac WLAN connections can often create high load peaks, which can saturate an entire 80 MHz channel and disturb other subscribers.

 

The article was published in German. Here you find the online version of the German article.