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 using Twilio Client.
Your firewall should allow outgoing UDP to the public internet from the browsers that will be using Twilio Client, and allow return traffic in response. If you are operating a restricted network that requires you to allow specific media IPs, our recommendation is to specify the region in your application. If your router includes SIP Application Level Gateway (ALG) function or Stateful Packet Inspection (SPI), disable both of these functions.
- You can find our fixed range of IP addresses, and examples of how to specify your region in code at Twilio Client - Regions (Twilio Docs).
- You can find port and bandwidth requirements in our article What are Twilio Client's Network Connectivity Requirements.
Note: It is possible to use Twilio's Network Traversal Service to restrict media traffic to UDP port 3478 by using our TURN servers. The regional media IPs will still need to be allowed, as will the TCP signaling port and hosts listed above. For more information about using TURN, please see our Network Traversal Service site.
Local network conditions have the biggest impact on voice quality. Jitter, latency, and packet loss can be the biggest contributors to voice quality issues in any VoIP network.
|Latency||The time it takes the RTP (media) packets to arrive at the destination||Causes media delivery delays, callers may speak over the top of each other.|
|Packet loss||Packets that don't make it to the final destination||Causes gaps and cut-outs in media, callers may not hear the other side.|
|Jitter||Packets that arrive at the destination out of order||Cause a ‘robotic’ distortion effect in media, or packet loss when overrunning the jitter buffer|
Latency: High latency can substantially degrade a caller's experience. While there will always be some latency between the codec algorithm, the jitter buffer, and network traversal, the goal is to keep this to a minimum. Callers typically start to notice the effect of latency once it breaches 250ms, and find latency above ~600ms to be nearly unusable. Here are some strategies to minimize latency on your network:
- Some lower bandwidth fixed internet connections can often have a higher latency. If possible, upgrade your internet connectivity.
- Stick to high-bandwidth connections. Mobile networks such as 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.
Jitter: Packet loss, most frequently jitter-induced packet loss, can make a big impact on your VoIP call quality. Wi-Fi can be particularly bad for creating jitter. Here are some strategies to minimize jitter on your network:
- Use fixed ethernet instead of Wi-Fi whenever possible
- Reduce packet conflicts on Wi-Fi by reducing the number of devices operating on the same channel.
- Avoid large data file transfers over the same Wi-Fi environment concurrently with voice.
- Avoid bufferbloat, which can result in high latency, and bursts of jitter. We recommend ensuring your router is configured with a low buffer size, as high jitter cannot be masked by a buffer without introducing artificial delay, and often choppy audio.
Note: 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.
Supported Operating Environments
The supported operating environments are based on the OS level for mobile, and the browser release level for Web.
Web Browsers: We test with the current major revision of the browser, and 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 find supported desktop web browsers in our article Which Browsers Support WebRTC.
- You can check if your browser is supported and configured correctly at our Client test site: https://networktest.twilio.com/
PC Hardware: Hardware can impact voice quality. Different audio cards and driver combos can interact in different ways. Twilio 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 Hardware: Hardware support in general is determined by the Mobile OS level supported by the 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. If you’re experiencing a voice quality issue which you suspect to be due to mobile hardware, please perform the following tests if possible:
- Test behavior with and without a headset
- Test on different models of hardware
If you discover any issues in your testing, please report it to Twilio.
Mobile OS: 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.
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 the speaker and microphone, and therefore minimize echo. That being said, headset selection should be made carefully.
PC Headsets: For lower end PC hardware, we recommend USB Headsets over 3.5mm standard audio jack headsets. This allows you to bypass the native sound board. For machines with a higher end integrated sound board the 3.5mm connection should 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: 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 the included adapter, rather than your device’s native Bluetooth receiver, to avoid interoperability issues.
Please note that Bluetooth support on mobile devices can vary significantly, and some devices may not provide the programmatic ability for Bluetooth answer/hangup buttons to be passed to non-native applications.
Static: Static and white noise issues with your client audio can often be due to a misbehaving or misconfigured headset. If you are experiencing static, try reproducing this issue with different headset hardware or no headset hardware in order to narrow down potential sources.
- Getting Started with Twilio Client
- Client Best Practices (Twilio Docs)
- What are Twilio Client's Network Connectivity Requirements?
- Constrain the Client Audio Sources in Google Chrome
- Troubleshooting Common Problems with Twilio Client