Short answer
Choppy or robotic audio means that packets are being lost or delayed between your users and Enfonica, usually at the PBX's server, in your network, or on a user's connection. If a phone menu doesn't recognize keypresses, they usually aren't sent as RFC 2833 events, or they're lost on a forwarded leg of the call.
- Applies to
- Cloud SIP, Phone Numbers
- Works with
- Any SIP PBX or SBC
- Who can do this
- Whoever manages your PBX and your network
Check for a known incident first. If there is one, we're already working on it, and there's nothing to change on your side.
Checking Enfonica system status…
Status pageOn this page
What are you seeing?
- Audio is choppy, robotic, or breaks up
- There's a delay, and people talk over each other
- Phone menus don't recognize keypresses
Audio is choppy, robotic, or breaks up
Call audio travels as a steady stream of small packets. When some are lost or arrive late, words break up, drop out, or sound robotic. Start by finding where the packets go missing. Your PBX (phone system) can usually tell you.
Many PBXs, including 3CX, show packet loss for each leg of a call. On the leg between your PBX and Enfonica, that figure comes from the reports that Enfonica's media edge sends back to your PBX (RTCP receiver reports). These reports describe the audio we received from you. Loss there means that packets went missing between where the audio was made, on your side, and Enfonica.
The PBX's server can't keep up
A PBX that runs short of processing power sends audio unevenly, and every call on it suffers at once.
Check
Look at the PBX's CPU use when the audio is choppy. This is the cause if several users have choppy audio at the same moment, and CPU use is high at those times. Cloud servers sold as "burstable" are a common cause, because they slow down after their CPU credits run out. Backups and snapshots of the server can also pause it briefly.
Fix
Make these changes:
- Move the PBX to a server size that isn't burstable.
- Schedule backups and snapshots outside business hours.
- Turn on your cloud provider's accelerated networking option, if it has one.
The PBX is converting every call's audio
If your trunk's codec list includes a codec that Enfonica doesn't use, such as Opus, your PBX can end up converting audio between that codec and G.711 on every call. This adds load to its server. It doesn't improve quality, because the phone network beyond Enfonica carries G.711 or similar anyway.
Check
Look at your trunk's codec list. This is the cause if it includes codecs other than G.711 A-law (PCMA), G.711 u-law (PCMU), and G.729.
Fix
On your Enfonica trunk, set the codec list to G.711 A-law (PCMA) only.
Audio is lost between your users and the PBX
When your PBX passes audio straight through, packets lost between a user's phone and the PBX never reach Enfonica, so they also show up in Enfonica's reports.
Check
Look at your PBX's quality reports and at where the affected users work. This is the cause if the leg between the extension and the PBX shows loss too, or if the affected users work from home, on Wi-Fi, or over a VPN.
Fix
Ask an affected user to make a test call from a wired connection without the VPN. If that call is clear, the fix is in their local network or internet connection.
Packets are lost between your PBX and Enfonica
Check
Run a packet capture on your PBX during an affected call. This is the cause if the capture shows audio leaving the server steadily, with no gaps, while the PBX still reports loss on the trunk leg.
Fix
Send us three to five example calls with their times, and the capture. We'll look at the audio statistics recorded on our side for those calls and work out where the packets went.
There's a delay, and people talk over each other
When every call has a delay, check how far the audio travels between your PBX and Enfonica's edge, which is in Sydney.
The call's audio takes a long route
Check
Run a traceroute from your PBX to 35.189.19.106. It shows the route and the time each hop takes. This is the cause if every call has the same delay, and your PBX is hosted outside Australia, or calls go through a VPN that sends traffic to another city or country first.
Fix
Host your PBX in Australia, close to Sydney. Send voice traffic directly to Enfonica rather than through the VPN.
Phone menus don't recognize keypresses
When a caller presses a key, the tone (DTMF) travels in the call's audio stream as a separate event. A standard called RFC 2833 defines these events. Keypresses go missing when they're sent another way, or when one leg of the call doesn't pass them on.
Your PBX sends keypresses in a way the call can't carry
Cloud SIP carries keypresses as RFC 2833 events. It doesn't accept keypresses sent as SIP INFO messages.
Check
Call a few phone menus from your PBX. This is the cause if keypresses from your PBX fail on every menu you call, while the same menu works from a mobile.
Fix
In your PBX's trunk settings, set the DTMF mode to RFC 2833. Some PBXs call it RFC2833, RTP event, or out-of-band.
Keypresses are lost on a forwarded leg of the call
When a number forwards to another number or service before it reaches the menu, each leg of the call has to pass the keypresses on.
Check
Call the menu's number directly, and then call it through the number that forwards to it, such as a 1300 number with another provider. This is the cause if the menu works on the direct call and fails on the forwarded one.
Fix
Raise it with the provider of the forwarding leg. Include the test results that show the difference.
Only callers from one network are affected
Check
Look at which callers are affected. This is the cause if keypresses work from most phones, but not from mobiles on one network.
Fix
Send us example calls with the caller's number, the time, the keys pressed, and the caller's network. This is a fault for us to raise with the carrier.
What helps us find a quality problem?
Enfonica doesn't record call audio unless you turn on call recording, so the most useful evidence comes from your side. Along with the details in What to send us, send these:
- Three to five example calls, with the time the problem was heard.
- A packet capture from your PBX that includes the audio (RTP).
- For keypress problems, a note of when each key was pressed.
What to send us
Include these and we can find the call straight away.
- The number that made the call and the number it called, in full international format (for example +61255501234).
- The date and time of the call, with your timezone.
- Whether the call was inbound or outbound.
- The call ID, if the Console shows the call.
- What happened: an error message, silence, a busy tone or a dropped call.
Our support team are telco specialists, backed by the engineers who run the network.
Related
Was this helpful?
What was the problem?
Thanks for telling us.