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 Twilio Client.
Ports and Network Connectivity Requirements
Please refer to this FAQ for necessary requirements regarding your network configuration, including ports, bandwidth and firewall configuration.
Additionally, 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://netalyzr.icsi.berkeley.edu/ for a much more detailed network scan, including testing for bufferbloat.
You can find a fixed range of IP addresses in the Twilio network which signaling and media will come from in our Twilio Client Regions documentation.
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.
- 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.
Note that 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.
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. Read more here.
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 Twilio Client 1.3 or higher to take advantage of Twilio’s Global Low Latency routing infrastructure.
For each concurrent call, allow:
- WebRTC: 8 kB/s. This does not scale based on bandwidth.
- 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, 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.
Hardware can impact voice quality. Different audio cards and driver combos can interact in different ways. Twilio 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 8 and iOS 7.1.2.
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
Report any issues you discover to Twilio
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 Twilio Client calls in order to provide acoustic isolation between speaker and microphone, and therefore minimize echo. However, headsets selection should be made carefully.
For lower end PC hardware, we recommend USB 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.
Twilio test with a range of Plantronics and Logitech headsets. A full list of tested headset hardware will be made available in the future.
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.
Note that a ‘static’ noise issue with your client audio can often be due to a misbehaving or misconfigured headset. If you are experiencing static, try with different headset hardware or no headset hardware in order to narrow down potential sources.
Twilio Client Troubleshooting
Please refer to this FAQ for troubleshooting common issues with Twilio Client.