Basic Troubleshooting

First-line fixes for the most common phone-system issues: call quality, audio problems, dropped or failed calls, and devices that won't register. Most issues in this guide can be resolved without contacting support.

If you're setting up a new office or network rather than fixing a problem, start with Network Requirements instead.

How to use this guide

Most phone problems fall into one of three patterns:

1. The audio is bad. Choppy, robotic, garbled, echoey, or one direction is silent.
2. The call didn't work. It dropped, never connected, never rang the right person, or never rang at all.
3. A device or app is broken. A desk phone won't boot or register, the softphone won't sign in, a handset shows the wrong user.

A fourth pattern is the AI agent isn't behaving: it won't answer, hangs up early, transcribes wrong, or doesn't transfer correctly. See VoiceAI symptoms.

The fastest path is almost always the same:

1. Run the quick triage below to figure out the shape of the problem.
2. Open the Call Quality dashboard in the admin portal to see whether the numbers confirm what your users are reporting.
3. Jump to the matching symptom section.
4. If you can't resolve it yourself, use the information to collect before contacting support checklist so the support team has what they need on the first reply.

Quick triage (start here)

Before doing anything else, answer these four questions. Your answers point you at the right section.

1. How many people are affected?

• One person at one location: most likely a device, headset, network, or user-config issue. Start with Audio and call-quality symptoms or Device and app symptoms.
• Multiple people at one location: most likely that location's network or internet connection. Start with Network diagnostics.
• Multiple people across multiple locations: could be a carrier or platform issue rather than anything on your side. Collect the details below and contact support.

2. Did anything change recently? A new router, an internet provider change, a new firewall, a Wi-Fi reconfiguration, a phone moved to a new location, an update to a dial plan. Most "it just started happening" problems trace back to a change in the last 24 to 72 hours.

3. Is it one direction or both?

• Both sides of every call sound bad: network or platform.
• Only one direction can hear: nearly always a NAT, firewall, or routing issue. See One-way audio.
• Only inbound or only outbound calls fail: a routing or dial-plan issue, not network.

4. Is it every call, or only some? A problem on every call points at a setting or the network; a problem on some calls points at a specific number, route, device, or time of day.

Write these four answers down (or include them when you contact support). They speed up every later step.

Open the Call Quality dashboard

Before deep troubleshooting, open the Call Quality dashboard in the admin portal. It gives you a numbers-based picture of what's actually happening.

What to look for:

• Avg. MOS. A single quality score for the selected window; see the bands below.
• Avg. Jitter and Avg. Packet Loss. If either is elevated, your network is the most likely cause.
• MOS Over Time chart. Is quality steady or did it dip at a specific time? A sharp drop usually corresponds to a network event, an internet provider issue, or a change at one of your sites.
• Lowest Quality Calls table. Pull up the worst calls and click into them. The Call Detail page shows per-leg quality metrics so you can see whether the bad leg was the outside caller's side (carrier or platform) or your side (your network or device).

How to read the numbers:

MOS	What it means
4.3 – 5.0	Excellent. Indistinguishable from in-person conversation.
4.0 – 4.3	Good. Minor issues, callers unlikely to care.
3.5 – 4.0	Fair. Occasional glitches noticeable.
3.0 – 3.5	Poor. Callers likely to complain.
Below 3.0	Unacceptable. Conversation is difficult.

Where the impairment is (compare against the thresholds table):

• High jitter usually points to network instability, often Wi-Fi or a congested internet connection.
• Packet loss in the "Problematic" range degrades calls noticeably. Above 3% and calls become unusable.
• High round-trip time causes the conversational delay where people talk over each other.

If MOS is consistently Good or Excellent but users are still reporting bad calls, the problem is probably at the device, headset, or speakerphone level rather than the network. Skip to Device and app symptoms.

Network requirements at a glance

What a healthy voice network looks like (bandwidth, the ports and destinations to allow, SIP ALG, NAT keepalives, QoS, Wi-Fi) is documented in full in Network Requirements. That page is safe to share with your IT contact, so this guide points to it rather than restating it.

The one thing worth keeping in front of you while you troubleshoot is the set of quality thresholds voice is sensitive to. These are the same numbers the Call Quality dashboard reports:

Metric	Good	Acceptable	Problematic
Jitter	Below 20 ms	Below 30 ms	Above 30 ms
Packet loss	Below 0.5%	Below 1%	Above 1%
Round-trip latency	Below 100 ms	Below 150 ms	Above 200 ms

If a location sits consistently in the "Problematic" column, voice quality will suffer on any phone system, and the fix is on that location's network. Everything else (ports, firewall settings, NAT timeouts, QoS tagging) lives in Network Requirements; the symptom sections below link to the relevant part of it when it matters.

Audio and call-quality symptoms

Choppy, robotic, or garbled audio

What it sounds like: Words are cutting in and out, voices sound distorted or underwater, audio breaks up.

Most likely causes, in order:

1. Packet loss. Audio packets aren't arriving. Check the Call Quality dashboard for packet loss in the "Problematic" column of the thresholds table.
2. Jitter. Packets arrive in bursts instead of evenly. Check for jitter in the "Problematic" column.
3. Wi-Fi. Wi-Fi is the single biggest source of call-quality complaints. Wired Ethernet is always more reliable than wireless.
4. Network congestion. Another device on the same network is saturating the connection (large upload, video call, backup).

What to try:

1. Have the user switch from Wi-Fi to Ethernet for one test call, even if they have to plug into a router temporarily. If the call is clean on Ethernet, the problem is Wi-Fi.
2. On Wi-Fi, move closer to the access point and make sure the device is on 5 GHz, not 2.4 GHz.
3. Run a VoIP-grade network test from the affected location.
4. Pause any large uploads, cloud backups, or video calls and try again.
5. If your router supports QoS, enable it for voice traffic.

When to contact support: Network tests pass and MOS is still consistently Poor or worse across multiple users at the location.

One-way audio

What it sounds like: Caller A can hear caller B, but caller B can't hear caller A (or vice versa).

Most likely causes, in order:

1. Strict NAT or a restrictive firewall on your network. Outbound audio packets get out, return packets get blocked.
2. SIP ALG enabled on your router. SIP ALG modifies SIP traffic in ways that often break the return audio path.
3. Headset or mic-mute issue on the device. Easy to dismiss, but worth confirming first.

What to try:

1. Confirm the user's mic isn't muted, both physically and in software. Try a different headset.
2. On your router, disable SIP ALG if it's enabled. The setting name varies by manufacturer; common labels: "SIP ALG", "SIP Helper", "SIP Transformation", "VoIP passthrough".
3. Confirm your firewall allows UDP outbound and that there's no double NAT (router behind another router) on your network.
4. Softphones relay their audio automatically when the network is strict, so this is rare for them. For desk phones, NAT and SIP ALG are the usual suspects.

When to contact support: SIP ALG is off, the firewall is permissive, mic and headset are confirmed good, and one-way audio persists.

Echo or feedback

What it sounds like: The user hears their own voice come back at them, sometimes with a delay.

Most likely causes:

1. Speakerphone too close to the mic. Acoustic feedback. Use a headset.
2. Two devices on the same call. Sometimes a user accidentally answers on both their desk phone and softphone.
3. Bluetooth headset glitch. Reconnect or pair fresh.

What to try:

1. Use a wired headset.
2. Make sure only one device is in the call.
3. Lower speakerphone volume.

Echo is almost always a device or environment issue, not a network or platform issue.

Dropped calls mid-conversation

What it sounds like: A call disconnects after some duration, sometimes consistently around the same time (30 seconds, 30 minutes, an hour).

Most likely causes:

1. Audio path timeout on softphones. The audio path failed to establish properly and the connection drops around the 30-second mark.
2. NAT translation timeout on desk phones. Your router drops the NAT mapping after a period of inactivity.
3. Internet failover. Your internet connection briefly switched paths and the call couldn't recover.
4. Wi-Fi roaming. The user moved between access points mid-call.

What to try:

1. Check whether the drops are consistent in timing. A drop at exactly 30 seconds on a softphone suggests a firewall is blocking UDP and the TCP 443 fallback is blocked too, so no audio path can be established. Check the firewall against Ports and destinations in Network Requirements.
2. For desk phones, confirm the phone's registration is healthy (most phones show a registration status on their display). If it re-registers frequently, the router's NAT timeout is too short. Phones supplied with your phone service handle keepalives correctly by default; a phone you brought from a previous system may need its keepalive interval adjusted.
3. If drops line up with the user moving around, suspect Wi-Fi roaming.

When to contact support: Drops are consistent across multiple users and devices, and network tests pass.

Calls fail to connect (fast busy, dead air, ring with no pickup)

What it sounds like: A user dials and hears a fast busy tone, nothing at all (dead air), or normal ringback but the call never connects to a person.

Most likely causes:

1. Dial plan misconfiguration. The call is routing somewhere it shouldn't. Open the Dial Plans view in the admin portal and trace the route.
2. Number was ported away or not yet ported in. Check the number's status in the admin portal.
3. Carrier-side block. Less common, but the destination number is on a block list.
4. Outbound calling permissions. The user's role doesn't allow the type of call (international, premium rate).

What to try:

1. Try a different destination number. If it works, the problem is the original number.
2. Trace the call in the Call Logs (find the call by time, click into Call Detail). The status field tells you exactly where it ended.
3. Check the dial plan that handles the route.

Inbound calls don't ring

What it sounds like: People calling you go straight to voicemail, it rings forever, or it doesn't ring at all.

Most likely causes:

1. Dial plan or routing issue. The number is routing to voicemail, an inactive group, or a Voice App that's misconfigured.
2. Do Not Disturb is on for the user or the group. One deliberate exception: for a short period after a user dials an emergency number, calls ring them even with Do Not Disturb on, so a 911 call-taker calling back reaches them instead of their voicemail.
3. Phones aren't registered. No active device to receive the call.
4. Number not assigned to a user, group, or dial plan.
5. NAT mapping pruned by your router. The phone reports itself as registered, but the router silently dropped the NAT entry between keepalives, so the inbound call has nowhere to land. Common on enterprise firewalls and UTM appliances with aggressive UDP connection-tracking timeouts.
6. A cell phone's voicemail answered an earlier step. If a Find Me / Follow Me sequence, a ring group, or a call queue reaches someone on an external number, that phone's carrier voicemail answering counts as an answer, so the call connects to that voicemail and the remaining steps or members never ring. It looks like "the later steps don't work". The fix is Confirm Pick-Up (External), which requires the external number to press "1" before being connected. It is a per-user setting on the Find Me / Follow Me card (it also covers a queue agent reached on their cell) and a separate per-group setting on a ring group. A dial plan's External Number node has no such option yet.

What to try:

1. Confirm the number is assigned and routed correctly in the admin portal.
2. Check that the receiving user or group has at least one registered device. The Call Logs will show whether the call attempted to ring a device.
3. Test by calling the number from an outside line.
4. If the phone shows registered but inbound calls still don't ring, suspect NAT pruning. Reboot the phone (which forces a fresh registration and a new NAT mapping) and immediately try the call again. If the call works right after a reboot but fails later, your router is pruning the NAT entry more aggressively than the keepalive interval. See UDP connection tracking in Network Requirements for the fix.

Voicemail not delivering

What it sounds like: Voicemails come in but the notification, transcription, or email forward isn't arriving.

Most likely causes:

1. Email address on the user is wrong or notifications aren't enabled.
2. Email is being filtered as spam by your email provider.
3. Notification settings turned off at the user level.

What to try:

1. Verify the email address on the user's profile.
2. Check the recipient's spam folder.
3. Send a test voicemail and confirm it appears in the user's voicemail box in the admin portal (which confirms the voicemail itself worked) before assuming the notification chain is broken.

Caller ID wrong or showing "unknown"

What it sounds like: Outbound calls show a wrong number, or inbound calls show "Unknown" instead of a name.

Most likely causes:

1. The call was forwarded, and the caller ID is correct. A call that arrived on one of your numbers and was sent back out to an external number deliberately shows the original caller, not your own number. This covers a dial plan's External Number node, Find Me / Follow Me, a ring group's external member, a queue agent on an external number, and a user's blind transfer to an external number. The outbound caller ID setting is not consulted on these paths, so changing it has no effect. An attended (warm) transfer is the exception, from any device: the user called the target to consult first, so it shows the transferring user's number.
2. Outbound caller ID is set to the wrong number on the user, or on the account default the user falls back to. A location's primary number is not used for outbound caller ID, so changing it will not help here.
3. Caller name registration. "Caller name" (CNAM) is a separate registration from the number itself and can take days to propagate after a number is added.
4. The receiving carrier doesn't look up caller names (common on mobile networks). Nothing on your account can change this.

What to try:

1. Establish whether the user placed the call or it was forwarded. Only the first is a settings problem.
2. Confirm the outbound caller ID is set correctly on the user's profile in the admin portal. Each user can have a per-user outbound caller ID that overrides the account default; check that this is set to the number you expect.
3. Check that the number itself is still active with outbound calling enabled. If a user's override is inactive or has outbound calling switched off, the call does not fall back to the account default: it falls back to another active number on the account, which is a common cause of "the wrong number showed up".
4. For inbound "Unknown" calls, the calling party's name may not be in any directory, which is normal.

Device and app symptoms

Desk phone won't boot or shows no display

1. Confirm the phone is getting power: PoE from the network switch, or a separate power adapter. The phone's power LED should be on.
2. Confirm the network cable is in the LAN port, not the PC port.
3. If the phone is using PoE, try a different switch port. Some switch ports are non-PoE.
4. Reboot the phone by unplugging it for 30 seconds, then plugging it back in.

Desk phone won't register (shows "no service" or similar)

1. Confirm the phone is on the network. Most phones display their assigned IP address on the status screen. If it's 0.0.0.0 or self-assigned, the phone isn't getting DHCP.
2. Confirm your firewall allows the required ports.
3. Re-provision the phone from the admin portal. See Devices for the re-provision flow.
4. If it still won't register, contact support. A factory reset is sometimes the last step, and the procedure differs by phone model, so support will walk you through the right one.

Desk phone shows the wrong user or extension

The device is assigned to a different user than expected. Open the user's profile in the admin portal, reassign the device, and the phone will re-provision on its next check-in (usually within a few minutes; reboot the phone to force it).

Softphone won't sign in

1. Confirm the user's credentials are correct.
2. Confirm the user is active in the admin portal.
3. Try in a different browser or on a different network to isolate whether it's a local issue.
4. The user's browser must allow microphone access. Chrome, Edge, and Firefox prompt the first time; if the user previously denied the prompt, the permission has to be reset in browser settings.

DECT handset won't pair or shows "no base"

1. Confirm the base station is online and registered.
2. Bring the handset within a few feet of the base.
3. Re-run the pairing process from the handset menu (varies by manufacturer; usually under Settings → Registration).
4. If the base shows the handset is registered but the handset still says "no base", reboot both.
5. If pairing still fails, contact support. Resetting the base station and re-pairing every handset is the usual next step, and support will walk you through it for your model.

Admin portal symptoms

Every page says it can't be loaded right now

Every page shows "This page can't be loaded right now. Contact support if this persists." instead of its usual content. The admin portal can't currently reach your account, and nothing in it can be viewed or changed until that access is restored.

1. Reload the page after a minute.
2. If the message persists, contact support.

VoiceAI symptoms

The VoiceAI agent (a Voice App) is a configurable AI receptionist that answers calls, follows instructions, references an FAQ, and (when configured) looks up callers and books appointments via a webhook. Below are the common things that go wrong, and how to triage them.

Agent doesn't answer

1. Confirm the Voice App is wired into the dial plan that handles the affected number. Open the dial plan and look for a Voice App node on the path.
2. Confirm the Voice App is enabled and configured. An empty Instructions field or a missing greeting can cause the agent to fail to start.
3. Check whether the call is reaching the Voice App at all in the Call Logs. If the call ends before the Voice App node, the issue is upstream in the dial plan, not in the agent.

Agent hangs up early or seems confused

1. Review the agent's Instructions field. Vague or contradictory instructions are the most common cause of unexpected behavior.
2. Review the FAQ entries. The agent leans heavily on these for answers; if a caller asks something the FAQ contradicts, the agent will get confused.
3. Check call recordings or transcripts on the Call Detail page to see exactly what the caller said and how the agent responded. Most "the AI is broken" reports resolve into "the instructions or FAQ need a small edit."

Agent doesn't transfer to a person

The agent can perform a blind transfer to a person: it says a handoff sentence, then connects the caller to an extension or an outside phone number. It cannot yet do an attended (warm) transfer, which means speaking to the receiving person before handing the caller off.

If transfers aren't happening when they should:

1. Review the agent's Instructions. The agent transfers when its instructions tell it to; if they never mention when to transfer or who to transfer to, it won't. Spell out the trigger and the target, e.g. "If the caller asks for billing, transfer them to extension 101."
2. Confirm the transfer target is valid: an extension that exists on the account, or a full phone number. If the target user has no registered device, the transfer rings nothing; check device registration.
3. Check the transcript on the Call Detail page to see whether the agent attempted the transfer at all, then where the call went after it.

If callers should reach a person before the agent in some cases, handle that upstream in the dial plan instead: an IVR that offers "1 for our team, 2 to talk to our AI assistant", or a ring group that rings real people during business hours and falls back to the Voice App after hours.

Booking or scheduling integration isn't working

1. Confirm the scheduling webhook URL on the Voice App is correct and reachable.
2. Confirm the webhook secret matches the one configured on your scheduling system.
3. The webhook is signed; the receiving system needs to verify the signature. If your system isn't verifying correctly, requests will be rejected.
4. Check your scheduling system's webhook logs for any error responses sent back.

Transcription is missing or wrong

1. Transcription happens after the call ends. Wait a minute or two and reload the Call Detail page.
2. Accuracy depends on audio quality. If the underlying call had high packet loss or low MOS, transcription quality suffers. Check the Quality Metrics on the same Call Detail page.
3. Background noise, multiple talkers, and accents all reduce accuracy. This is a limit of speech-to-text in general.

Network diagnostics

When the Call Quality dashboard points at your network, confirm it using the validation tests and firewall checks in Network Requirements. Run them from a device on the same connection as the affected phones (wired if the phones are wired, the same Wi-Fi if they're wireless):

• Run the VoIP-grade network test and continuous ping (the Cloudflare speed test plus a ping over a few minutes), then compare the result against the thresholds above.
• Confirm SIP ALG is disabled on the router.
• Rule out double NAT.

If the tests pass but quality is still poor, contact support (see Information to collect before contacting support). Network Requirements also covers Wi-Fi, PoE, DHCP, and QoS specifics if you need to go deeper.

Information to collect before contacting support

How quickly support can resolve an issue depends almost entirely on the details you send with your first message. Collect the following before you write:

• Account name as shown in the admin portal.
• Affected location, if you have more than one.
• Affected users or phone numbers, with caller and called numbers for any specific failed calls.
• Exact timestamp of the failed call, with timezone (e.g., "2026-05-28 14:32 PT").
• Call ID from the Call Detail page if you can pull it.
• Symptom, in your users' words: "calls cut out", "people can't hear me", "ring with no answer".
• Reproducibility: one-off, intermittent, always.
• MOS / jitter / packet loss from the Call Quality dashboard for the affected window.
• Network test results if you ran one.
• What you've already tried so support doesn't suggest the same things back.
• Screenshots of any error messages or unexpected behavior.

A first message with this in it usually gets resolved in one round of back-and-forth. One without it usually takes three or four.

Glossary

• MOS (Mean Opinion Score): A 1 to 5 rating of perceived voice quality; see the MOS bands.
• Jitter: Variation in the arrival time of audio packets. High jitter makes audio choppy.
• Packet loss: Percentage of audio packets that fail to arrive. See the thresholds table.
• Latency / RTT (round-trip time): How long a packet takes to travel from one end to the other and back. High latency causes conversational delays.
• Codec: The format used to encode voice. Every call uses G.711, on desk phones, softphones, and outside lines alike.
• SIP: The signalling protocol used by desk phones to register and place calls.
• RTP: The protocol used to carry the actual audio.
• SIP ALG: A router feature that inspects and modifies SIP traffic. Usually does more harm than good with hosted VoIP. Turn it off.
• NAT (Network Address Translation): The mechanism a router uses to share one public IP across many private devices.
• STUN / TURN: Servers that help softphones work through NAT and restrictive firewalls.
• DSCP / QoS: Tagging that lets a router prioritize voice traffic over other traffic.
• PoE (Power over Ethernet): A way to power a desk phone through the same network cable that carries its data.

• Voice App: An AI agent configured to handle calls.

Related

• Network Requirements
• Call Quality
• Call Logs
• Dial Plans
• Devices

• Voice Apps