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 CallTrackingMetrics Client.
Ports and Network Connectivity Requirements
In order to check your overall firewall and port configuration, we recommend:
- http://www.netscan.co/ for a general scan
- https://pentest-tools.com/discovery-probing/udp-port-scanner-online-nmap for a UDP port scan.
- http://www.dslreports.com/speedtest bandwidth test to check your internet connection
At this time CallTrackingMetrics does not provide a fixed range of IP addresses in the CallTrackingMetrics network which signaling and media will come from. For more information: Routing to SIP Clients
If your router includes SIP Application Level Gateway (ALG) function or Stateful Packet Inspection (SPI), disable both these functions.
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 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 as determined by this tool should be around 100ms or less: http://netalyzr.icsi.berkeley.edu/
Not all routers allow for configuring buffer sizes, but some routers ship with defaults which 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 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 CallTrackingMetrics latest Client version to take advantage of CallTrackingMetrics’s Global Low Latency routing infrastructure.
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.
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.
You can check if your browser is supported and configured correctly here:
WebRTC is supported on Firefox and Chrome. ORTC in Microsoft Edge is supported in Client version 1.3 and later. Note: Calltrackingmetrics recommends using Chrome or Firefox as the default browser for CTM as there could be different behaviors utilizing the softphone on other web browsers.
Hardware can impact voice quality. Different audio cards and driver combos can interact in different ways. CallTrackingMetrics test 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.
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
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.
Headsets can improve audio quality by minimizing echo challenges. We recommend use of a headset on CallTrackingMetrics Client calls in order to provide acoustic isolation between speaker and microphone, and therefore minimize echo. Also, keep 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.
For lower end PC hardware, we recommend USB Wired Headsets, rather than 3.5mm jack headsets so that you bypass the native sound board. For machines with a higher end integrated sound board the 3.5mm connection can be fine.
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 in order 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.
Report any issues you discover to CallTrackingMetrics
MONDAY – THURSDAY
7:30am – 7:30pm, EST
7:30am – 5:30pm, EST