Best Practices for Softphone and SIP

The quality of a Voice over IP (VoIP) client call is heavily dependent on the environment that call is running in. From the device, the client is running on, to the network characteristics and firewall/router configuration – a successful VoIP deployment requires careful consideration of the end-to-end experience. This document is intended to share the best practices in configuring and selecting the best environment for VoIP calling over unmanaged networks using AuditCall Client.

If you are setting up a SIP configuration, please start with this article on SIP Setup.

Firewall Configuration

Ports and Network Connectivity Requirements

To check your overall firewall and port configuration, we recommend:

• https://pentest-tools.com/discovery-probing/udp-port-scanner-online-nmap for a UDP port scan.
• http://waveform.com/tools/bufferbloat bandwidth test to check your internet connection

IP Whitelisting

At this time AuditCall does not provide a fixed range of IP addresses in the AuditCall network which signaling and media will come from.  For more information: Routing to SIP Clients 

Other

If your router includes SIP Application Level Gateway (ALG) function or Stateful Packet Inspection (SPI), disable both these functions.

Network Conditions

Jitter, latency, and packet loss can be the biggest contributors to voice quality issues in any VoIP network.

• Latency is the time it takes the RTP (media) packets to traverse the network. Too much latency causes callers to speak over the top of each other.
• Packet loss is very common in IP networks, but certain networks such as WiFi can be particularly prone to high levels of packet loss. This causes sections of media to be missing and can cause the ‘robot’ distortion effect of media.
• ​The ​local network conditions have the biggest impact on voice quality. Packet loss, most frequently jitter-induced packet loss can cause the biggest impact. WiFi can be particularly bad for creating jitter.  Jitter is when packets don’t arrive in the same order they were sent. For small amounts of jitter, this can be resolved in the jitter buffer – a queue of media packets waiting to be played which can be shuffled into the correct order while they wait in the queue. The length of the jitter buffer introduced must be traded off against the impact of increased latency. Too much jitter cannot be resolved by a reasonable length jitter buffer without introducing too much delay, so instead results in jitter-induced packet loss causing choppy audio.

Strategies to minimize Jitter:

• Use fixed ethernet, not WiFi wherever possible
• Reduce packet conflicts on WiFi by reducing the number of devices operating on the same channel.
• Avoid large data file transfers going over the same WiFi environment concurrently with voice.
• ​Avoid bufferbloat. Bufferbloat occurs when your router is unable to transmit all the packets required, and builds up too large a queue (rather than dropping packets when the queue length starts making latency noticeable). This queuing causes large latency and bursts of jitter. The real-time nature of voice means that this is not helpful.

This can be caused either by a particular router Quality of Service (QoS) implementation selected, or particular router vendor defaults. We recommend ensuring your router is configured with a low buffer size. The perceived buffer size should be around 100ms or less.

Not all routers allow for configuring buffer sizes, but some routers ship with defaults that are not optimized for real-time VoIP networks. Open-source routers, enterprise-grade routers, and gamer-oriented routers are good candidates for providing the right configuration options and defaults.

If you have addressed the above issues and continue to have jitter related impact on your voice quality, you may consider configuring your router with QoS rules to prioritize traffic on the above media UDP ports. Given the large range of UDP ports, you should only do this with prior consideration to what other traffic may be flowing in that port range.

Latency

Latency can cause quality of experience issues for voice.

Callers typically start to notice the effect of latency once it breaches 250ms for a “mouth to ear” trip, and above ~600ms the experience is unusable.

Note that there will always be some latency – the codec algorithmic time, the jitter buffer, and the network traversal time together will always introduce some latency. The object is to minimize it and keep the total trip time below 250ms.

Strategies to minimize Latency:

• Some lower bandwidth fixed internet connections can often have a higher latency. If possible, upgrade your internet connectivity.
• LTE (mobile 4G Data) can often have high latency.
• ​Ensure you’re using AuditCall latest Client version to take advantage of AuditCall Global Low Latency routing infrastructure.

Bandwidth Requirements

For each concurrent call, allow:

• WebRTC: 8 kB/s. This does not scale based on bandwidth. On browsers using the Flash fallback bandwidth requirement is 6 kB/s.
• ​Mobile: 6 kB/s

Supported Operating Environments

The supported operating environments are based on the OS level for mobile, and the browser release level for web.

Web Browser

We test with the current major revision of the browser along with the previous major browser revision. That is if the current release version is N, we test with N, and N-1. We also proactively test on the development train for future releases (e.g. Chrome Canary) in order to identify upcoming changes in WebRTC support.

WebRTC is supported on Firefox and Chrome. ORTC in Microsoft Edge is supported in Client version 1.3 and later.  Note: AuditCall recommends using Chrome or Firefox as the default browser for AuditCall as there could be different behaviors utilizing the softphone on other web browsers. 

PC Hardware

Hardware can impact voice quality. Different audio cards and driver combos can interact in different ways. AuditCall tests many variations, but it’s impossible to cover all possible firmware interactions.

If you’re experiencing voice issues, first try the same test on different hardware to identify if it’s a hardware-specific issue.

Mobile iOS

We test with the current major release of the mobile OS, and the most recent update of the previous major release, e.g. iOS 13.4.1

Mobile Hardware

Hardware support in general is determined by the Mobile OS level supported by the hardware.

If you’re experiencing a voice quality issue which you suspect to be due to mobile hardware:

• Test behavior with and without a headset
• ​Test on different models of hardware

Android Hardware in particular has a large variation in behavior. Even the same model can vary from region to region in areas such as AGC and Echo Cancellation behavior.

Headset Hardware

Headsets can improve audio quality by minimizing echo challenges. We recommend the use of a headset on AuditCall Client calls in order to provide acoustic isolation between speaker and microphone, and therefore minimize echo. Also, keep the microphone 2 finger-widths from the corner of your mouth for optimal audio input.  (Refer to the manufacturer manual for their best practices) Headsets selection should be made carefully.

Wired Headsets

For lower-end PC hardware, we recommend USB Wired Headsets, rather than 3.5mm jack headsets so that you bypass the native soundboard. For machines with a higher-end integrated soundboard, the 3.5mm connection can be fine.

Bluetooth Headsets

Bluetooth headsets can present unique challenges, as each headset operates slightly differently. If your headset came with a USB Bluetooth adapter, we recommend you pair it with that rather than your device’s native Bluetooth support to avoid Bluetooth interoperability issues.

Note that Bluetooth support on mobile devices can vary significantly and devices very often do not provide the programmatic ability for Bluetooth answer/hangup buttons to be passed to non-native applications.