Checklist: Softphone installation
October 2021
Introduction
The use of softphone functions and VoIP telephony as a real-time application poses a special challenge to VoIP installations. These challenges are found in the invisible behavior of the network. Wherever real-time communication has not been used, the quality of the network can be "heard" in softphone conversations.
Processing e-mails, copying files, or using industry software in the browser do not make any special demands on the real-time behavior of the network infrastructure. Whether the action takes 250ms longer or stalls briefly can be handled well. However, this is not a sustainable state for a real-time application and thus the user experience with VoIP telephony.
However, these negative effects are difficult to predict. Even a small test installation does not allow any conclusions to be drawn about the subsequent user experience.
With this checklist, we would like to provide initial information of possible upcoming challenges based on many VoIP readiness analyses conducted by an external service provider, thus enabling the implementation of a successful project.
Clarification of the framework
The following questions are intended to query the requirements for a smooth installation of a VoIP real-time application.
Very important
Network quality and network documentation
Is there up-to-date network documentation with all devices (e.g. firewalls, WLAN access points, routers, virtualizations, switches)?
This is important because every component in the network has an impact on the network quality and must be checked when analyzing softphone behavior.
Desktop virtualization
Is desktop virtualization in use?
Increased requirements on the real-time behavior of the connected headsets/video cameras in addition to higher requirements on the server regarding real-time behavior.
Devices in use
Are smartphones and laptops used in the WLAN network?
Uniform coverage of the WLAN in the building is relevant here. At the same time, the bandwidth in the WLAN must be designed for parallel use of several softphones, and switching between WLAN access points must be implemented without interruption.
QoS Quality of Service settings
Are Quality of Service settings (DiffServ) consistently mapped across all devices?
To ensure consistent quality, it must be possible to implement the configuration consistently across all devices.
Important
Headset/camera sharing for desktop virtualization
Are the headsets/video cameras used for desktop virtualization approved by the respective manufacturer?
Not all headsets/video cameras are equally suitable for desktop virtualization. Therefore, this should be ensured in advance.
VPN Virtual Private Networks
Is the use of VPN planned for the connection of the workstations?
VPN places increased demands on the hardware due to additional encryption, which can easily lead to overloading of the VPN hardware. Switching to UDP for VPN can free up additional reserves here and improve real-time behavior
Private cloud – external data center – packet prioritization
Is the installation of the server components planned in an external data center (private cloud)?
The selection of services in the data center and the connection of the softphones via an internet connection are higher data volumes with real-time requirements and therefore depend on a packet prioritization of the IP packets.
Relevant, for critical application scenarios
Test installation
Is a permanent test installation planned for a selected group of people?
A (full-fledged) test installation is used to check whether changes in the network configuration work with the test installation before they are implemented for all employees. Also, in case of complications, individual employees can be moved to the (full-fledged) test installation to investigate phenomena in more detail.
Experience from past VoIP readiness analyses
From various softphone installations, we could identify some recurring phenomena through past VoIP Readiness analysis that have had a negative impact on the user experience. These phenomena can only be identified through an in-depth analysis of the network. These analysis tools are not part of our software and require collaboration with external experts and are only possible through an on-site deployment and 24/7 measurement over 5 working days. This is the only way to perform a comprehensive analysis of the network with all effects depending on the working hours.
Broad/multicast level clearly too high
Explanation: Broad/multicasts are one of the basic functions of data communication in the LAN, but too much accumulation leads to sporadic interference, especially in real-time applications. Based on years of experience, an aggregated broad/multicast value of 100 per 5 seconds can be regarded as the maximum tolerable limit for interference-free operation.
Example screenshot: Packet analysis broad/multicasts
Possible cause | printers, software deployment solutions |
---|
Frequent packet loss from the internet
Description | From the direction of the firewall (internet), several RTP streams with expected clustered packet loss are detected |
---|---|
Rating | Expected, that's how it is. |
Possible cause | Lack of transmission quality on the internet |
Recommendation | No recommendation is possible |
Strong jitter from the internet
Description | Numerous RTP streams with expected high jitter were registered from the direction of the firewall (internet) |
---|---|
Rating | Expected |
Possible cause | Lack of transmission quality on the internet |
Recommendation | No recommendation is possible |
Layer 2 prioritization (VLAN)
Description | Only isolated VLAN tags can be detected in the IP infrastructure. However, in no case was a VLAN priority used ('BE') |
---|---|
Rating | Critical, because VoIP traffic cannot be adequately handled in the IP infrastructure in this way |
Possible cause | Configuration of the hosts/applications and the IP infrastructure |
Recommendation | It is recommended to implement an end-to-end VLAN concept associated with correct prioritization ('VO') |
Layer 3 prioritization (DiffServ)
Description | In the IP infrastructure of Renfert, the DiffServ prioritization is not executed consistently – in many cases, the priority is missing |
---|---|
Rating | Critical, as DiffServ is an adequate means to appropriately prioritize real-time traffic (VoIP) in the IP infrastructure |
Possible cause | Configuration of the hosts/applications and the IP infrastructure |
Recommendation | It is recommended that DiffServ prioritization be made continuous and consistent, using only the correct value ('EF') |
Further articles
- Analysis of softphone behavior
- HD Voice/HD Telephony with ProCall Enterprise SIP softphone functionality
- Network Jitter or Round Trip Time – which is more important when testing or monitoring a WebRTC application?