What are common UCaaS call quality problems?

A UCaaS call sends your voice as a stream of small data packets, many of them every second. The app at the other end turns them back into speech, so the sound stays clean only while the packets keep arriving steadily. We follow that path step by step in how VoIP works.

Microsoft's network guidance for Teams pairs three symptoms with possible causes. Calls that have static, cut out or sound like robots could be jitter or packet loss. Calls that keep dropping might be a firewall or proxy blocking traffic. A service that runs slowly may be short of bandwidth.

Packet loss means some packets never arrive. Jitter means they arrive unevenly, and some come too late to be used. In both cases the app has less to play than the speaker said, and the listener hears the gaps.

A symptom doesn't identify its cause. The same choppy sound can come from a crowded Wi-Fi network, a congested office connection or a laptop with too many programs open, and nothing in the sound tells you which one you have. Microsoft's pairings are places to look first.

Lag is a different complaint. The words arrive intact but late, so each person starts a sentence just as the other one does. Anything that lengthens the route between the two callers adds to it.

Microsoft wrote its guidance for Teams, but the mechanisms it describes belong to the network, so they're worth knowing on any hosted voice service.

Start with Wi-Fi. Microsoft notes that Wi-Fi networks aren't necessarily designed or configured for real-time media. The 2.4 GHz band is often affected by other consumer devices, and access points set too close together on the same channel compete with each other. If calls break up in one conference room and sound fine at a wired desk, compare that room's wireless coverage before you look anywhere else.

A VPN is the second place to look. Microsoft says VPNs are typically not designed or configured to support real-time media, and some don't support UDP, which Teams needs. A VPN can also send a home worker's call through the company network and back out again. That can put the call on a path into the service that starts farther from the user, which adds delay and jitter. Microsoft's recommendation is a split tunnel, where call traffic goes straight to the service and other traffic stays on the VPN. That's a change to plan with whoever runs your VPN.

Firewalls come next. Microsoft asks administrators to make sure the firewall doesn't change the mapped NAT addresses or ports for UDP. It also asks them to give the NAT pool enough public addresses that ports don't run out, because port exhaustion leaves users and devices unable to connect. Both are settings to correct on a firewall that stays switched on.

Voice by itself needs little bandwidth. Microsoft recommends 58 kbps in each direction for a Teams audio call, counted per device, against 1,500 kbps for a one-to-one video call. Those are Microsoft's figures for Teams, and other providers publish their own. They still show the proportion. A connection that carries a voice call comfortably can run short once video, screen sharing and the rest of the office's traffic share it. We cover the planning in what UCaaS bandwidth requirements a business should plan for, and the arithmetic for a single call in how much bandwidth a VoIP call uses.

On a network you manage, quality of service settings, or QoS, let voice go ahead of traffic that can wait, such as a software download. Microsoft's call quality overview recommends setting it up on your internal network, and it adds that an organization that's small enough might not need it. QoS works where your own equipment makes the decisions. A home worker's broadband and the public internet beyond your office aren't yours to prioritize.

Echo and one-sided silence can start at the desk, with no network fault involved.

Echo has a simple mechanism. Microsoft's echo troubleshooting page for its calling developers describes it as the microphone picking up sound from the speakers, which creates a loop. Software removes much of that, but the same page says it can't remove every echo, and two devices in one room on the same call make its work harder. The page calls headphones the fastest fix, because sound played through them doesn't reach the microphone.

The familiar office case is several people in one room who each join a meeting on their own laptop. Microsoft's meeting audio guidance says to keep only one device's microphone and speaker on in a room. When the room has its own meeting device, people joining on a personal laptop should choose the audio-off option.

When you can't hear the other person, the devices are the first thing to rule out. Microsoft's speaker help page is a device checklist, and it opens by splitting the question between your speaker and the other person's microphone. If you're the only one who can't hear them, it points you to your own speaker. The checks are plain: the right speaker is selected in the app, it isn't muted, and a Bluetooth headset is charged and not connected to another device. The Teams desktop app also has a test call that records a short message and plays it back, which tries the microphone and the speaker in one go. That test isn't available in Teams on the web.

The computer deserves a look too. The same meeting audio guidance says that sound shared from a computer running a lot of applications can lag or cut out. We'd take the check further. A loaded laptop is worth ruling out before you change the network, because the symptom is the one from the network section and the cause would sit on the desk.

Device checks don't cover every silent call. If they pass and one side still hears nothing, the cause is somewhere else, and the provider needs a precise report. Tell them which side couldn't hear, because the direction narrows what their support team has to examine.

Suppose a 25-person firm uses Atlantech Online's hosted phone service, with desk phones in the office. Atlantech's UCaaS page describes a phone system that runs in Atlantech's cloud, a softphone whose calling features are tied to the business dial plan, and mobile apps for Android and iOS. That design helps with troubleshooting, because one person can take the same business calls on more than one device. The user stays the same while the device and the network change.

Say two people who work from home take calls on the laptop softphone and report choppy audio most afternoons, and nobody in the office does. Assume their laptops connect through the company VPN and their phones don't use one. On an afternoon when the trouble is present, each of them takes a few calls on the mobile app over cellular data. That swap changes two things at once, the device and the network. Clear calls there show that the service can reach those two people cleanly at that hour, but they don't say whether the laptop or the home network was at fault.

A second test, made in the same afternoon conditions, narrows it further. Each person takes a few calls on the mobile app while the phone is on the home Wi-Fi. If the choppiness comes back, attention moves to the Wi-Fi and whatever else uses the home connection at that hour. If those calls are clear as well, attention moves to what's specific to the laptop: its headset, the programs open on it, its own Wi-Fi connection and the VPN its calls run through. Neither result proves a cause, but each one tells the firm where to look next. The home side of that setup has its own answer in how to set up UCaaS for a remote team.

The firm then writes down what it found before it contacts anyone. A useful report gives the date and time of a bad call, the users or numbers on both ends, the device and network each person was on, and what was heard, including which side heard it. With that, a support team can find the specific call in its own records instead of starting from "calls are bad."

Atlantech's page advertises 24/7 customer support, and its call analytics include historical and live call data and call logs. The firm sends its report to support and asks them to examine those specific calls.

Some platforms put per-call quality records in the administrator's hands, and Microsoft Teams is a documented case. According to Microsoft's call quality overview, the Teams admin center shows the devices, networks and connectivity behind a specific user's calls and meetings. The Call Quality Dashboard shows quality across the whole organization.

Microsoft describes the two being used together. A support specialist looks at one user's bad call and passes it to an engineer. The engineer notices that the trouble may be tied to a site. A network engineer then checks the dashboard to see whether the whole site shows the same problem. It's the same narrowing by who is affected, done with records in place of interviews. A different service will have different tools, so it's worth learning what yours offers before the first complaint arrives.

Once the evidence points somewhere, change one thing and make the same kind of call again. Suppose you move a user to a wired connection, replace the headset and adjust the firewall on the same afternoon. A better call tomorrow won't tell you which change mattered, or what to do when the next person reports the same thing.