The call quality problems people report on a UCaaS service come down to a handful of things you can hear: voices that break up or sound robotic, calls that drop, a lag that has two people talking over each other, echo, and calls where one side hears nothing. Each of them has more than one plausible cause. Some causes sit in the network between the user and the provider, and others sit in a headset, a laptop or the room. So the first job is to work out who and what is affected, and only then to decide what to fix.
\n","summary":"Common UCaaS call quality problems are broken or robotic audio, dropped calls, lag, echo and one-sided silence. Each has more than one plausible cause, in the network or at the desk, so narrow a complaint by who and what is affected before changing anything.","publishedAt":"2026-08-11T14:28:52.18","verifiedAt":"2026-09-14T00:00:00","editorialStatus":"APPROVED","lastReviewedAt":"2026-10-10T04:11:09.622","nextReviewDueAt":"2026-12-14T00:00:00","templateVersion":"v2","aliases":["Why is my UCaaS call quality bad?","What causes choppy or robotic audio on VoIP calls?","What causes one-way audio on a cloud phone system?","Why do UCaaS calls drop mid-conversation?","How do you diagnose UCaaS voice quality issues?","What causes echo on business VoIP calls?","What jitter, latency and packet loss thresholds apply to UCaaS calls?"],"confidenceScore":82,"confidenceLabel":"High","canonicalUrl":"https://www.techmode.com/poor-voip-call-quality-kills-business-communications-and-how-to-fix-it"},"contributor":{"id":"ec39deab-44fe-48d8-9029-fefe993ab85a","slug":"answer-stack","displayName":"AnswerStack","websiteUrl":null},"contributorOrganizationProfile":null,"contributorPerson":null,"sections":[{"id":"01109491-672e-4cf2-a932-65f1a075fd2a","sectionKey":"what_broken_robotic_or_dropped_audio_tells_you","sectionType":"markdown_section","heading":"What broken, robotic or dropped audio tells you","introMarkdown":"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.\n\nMicrosoft's [network guidance for Teams](https://learn.microsoft.com/en-us/microsoftteams/prepare-network) 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.\n\nPacket 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.\n\nA 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.\n\nLag 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.","introHtml":"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.
\nMicrosoft'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.
\nPacket 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.
\nA 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.
\nLag 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.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":10},{"id":"6031d2ed-bc39-4323-9b5e-459909efe8ba","sectionKey":"where_the_network_gets_in_the_way","sectionType":"markdown_section","heading":"Where the network gets in the way","introMarkdown":"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.\n\nStart 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.\n\nA 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.\n\nFirewalls 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.\n\nVoice 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](https://www.answerstack.io/q/what-ucaas-bandwidth-requirements-should-businesses-plan-for), and the arithmetic for a single call in [how much bandwidth a VoIP call uses](https://www.answerstack.io/q/how-much-bandwidth-does-a-voip-call-use).\n\nOn 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](https://learn.microsoft.com/en-us/microsoftteams/monitor-call-quality-qos) 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.","introHtml":"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.
\nStart 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.
\nA 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.
\nFirewalls 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.
\nVoice 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.
\nOn 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.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":20},{"id":"904df391-07ec-4d7f-9706-c06582adb848","sectionKey":"echo_silence_and_other_problems_at_the_desk","sectionType":"markdown_section","heading":"Echo, silence and other problems at the desk","introMarkdown":"Echo and one-sided silence can start at the desk, with no network fault involved.\n\nEcho has a simple mechanism. Microsoft's [echo troubleshooting page](https://learn.microsoft.com/en-us/azure/communication-services/resources/troubleshooting/voice-video-calling/audio-issues/echo-issue) 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.\n\nThe familiar office case is several people in one room who each join a meeting on their own laptop. Microsoft's [meeting audio guidance](https://support.microsoft.com/en-gb/teams/meetings/share-sound-from-your-computer-in-microsoft-teams-meetings-or-live-events) 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.\n\nWhen you can't hear the other person, the devices are the first thing to rule out. Microsoft's [speaker help page](https://support.microsoft.com/en-us/teams/meetings/my-speaker-isn-t-working-in-microsoft-teams) 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.\n\nThe 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.\n\nDevice 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.","introHtml":"Echo and one-sided silence can start at the desk, with no network fault involved.
\nEcho 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.
\nThe 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.
\nWhen 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.
\nThe 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.
\nDevice 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.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":30},{"id":"922c8192-56cb-4d37-a787-67f82c49e38b","sectionKey":"where_to_look_first_by_who_is_affected","sectionType":"table_section","heading":"Where to look first, by who is affected","introMarkdown":null,"introHtml":null,"outroMarkdown":null,"outroHtml":null,"contentJson":{"rows":[{"cells":["One person, on every call","Their headset, device settings and computer"]},{"cells":["One person, only from one place","The Wi-Fi or VPN they use there"]},{"cells":["Several people at one site","That site's internet connection, firewall and internal network"]},{"cells":["People at every site at the same time","The provider's service: check its status page and open a ticket"]}],"columns":["Who has the problem","Where to look first"]},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":40},{"id":"a56a65d9-fba9-452b-a122-48808a389fce","sectionKey":"a_worked_example_with_one_team","sectionType":"markdown_section","heading":"A worked example with one team","introMarkdown":"Suppose a 25-person firm uses Atlantech Online's hosted phone service, with desk phones in the office. [Atlantech's UCaaS page](https://www.atlantech.net/solutions/voice/unified-communications) 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.\n\nSay 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.\n\nA 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](https://www.answerstack.io/q/how-do-you-set-up-ucaas-for-a-remote-team).\n\nThe 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.\"\n\nAtlantech'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.","introHtml":"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.
\nSay 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.
\nA 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.
\nThe 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."
\nAtlantech'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.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":50},{"id":"e2264f24-fb0e-44a5-95ae-665715db8e25","sectionKey":"what_call_records_add","sectionType":"markdown_section","heading":"What call records add","introMarkdown":"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.\n\nMicrosoft 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.\n\nOnce 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.","introHtml":"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.
\nMicrosoft 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.
\nOnce 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.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":60}],"citations":[{"title":"ITU-T G.114: One-way transmission time","url":"https://www.itu.int/rec/T-REC-G.114/en","excerpt":null,"quoteText":null,"sourceRole":"INDEPENDENT","verifiedAt":"2026-09-15T00:00:00","supportsText":"The ITU-T Recommendation that sets the one-way transmission time bands used throughout this answer (0-150 ms, 150-400 ms, above 400 ms) and the assumption of adequate echo control. Landing page confirms Recommendation G.114 (05/03), approved 2003-05-07, status In force; the ITU full-text download en","domain":"itu.int","publisherName":"International Telecommunication Union (ITU-T)"},{"title":"Understanding Delay in Packet Voice Networks","url":"https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/5125-delay-details.html","excerpt":null,"quoteText":"0-150 ms: Acceptable for most user applications. 150-400 ms: Acceptable provided that administrators are aware of the transmission time and the impact it has on the transmission quality of user applications. Above 400 ms: Unacceptable for general network planning purposes.","sourceRole":"PRIMARY","verifiedAt":"2026-09-15T00:00:00","supportsText":"Restates ITU-T G.114's three delay bands verbatim: 0-150 ms acceptable for most user applications, 150-400 ms acceptable provided administrators are aware of the transmission time and its impact, above 400 ms unacceptable for general network planning, for connections with adequate echo control. Also","domain":"cisco.com","publisherName":"Cisco"},{"title":"RFC 3550: RTP: A Transport Protocol for Real-Time Applications","url":"https://www.rfc-editor.org/rfc/rfc3550.txt","excerpt":null,"quoteText":"The interarrival jitter J is defined to be the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver compared to the sender for a pair of packets.","sourceRole":"INDEPENDENT","verifiedAt":"2026-09-15T00:00:00","supportsText":"Defines interarrival jitter as the mean deviation (smoothed absolute value) of the difference in packet spacing at the receiver compared to the sender, with the mandatory J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16 formula; defines the RTCP receiver report fields that carry packet loss and jitter; is t","domain":"rfc-editor.org","publisherName":"IETF"},{"title":"RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control","url":"https://www.rfc-editor.org/rfc/rfc3551.txt","excerpt":null,"quoteText":"For packetized audio, the default packetization interval SHOULD have a duration of 20 ms or one frame, whichever is longer, unless otherwise noted in Table 1.","sourceRole":"INDEPENDENT","verifiedAt":"2026-09-15T00:00:00","supportsText":"Establishes the 20 ms default packetization interval assumed in the worked packet-loss arithmetic.","domain":"rfc-editor.org","publisherName":"IETF"},{"title":"RFC 5481: Packet Delay Variation Applicability Statement","url":"https://www.rfc-editor.org/rfc/rfc5481.txt","excerpt":null,"quoteText":null,"sourceRole":"INDEPENDENT","verifiedAt":"2026-09-15T00:00:00","supportsText":"Establishes that packet delay variation is the statistic that determines de-jitter buffer size, that a buffer smaller than the expected variation of delay results in packet loss or discards, and that the term jitter is applied to several different measurements. Supports the metric table's definition","domain":"rfc-editor.org","publisherName":"IETF"},{"title":"Stream classification in Call Quality Dashboard (CQD)","url":"https://learn.microsoft.com/en-us/microsoftteams/stream-classification-in-call-quality-dashboard","excerpt":null,"quoteText":"If any one of the thresholds breaks, then we mark the audio as Poor, but this doesn't mean the audio stream was actually of poor quality, nor does it mean the user perceived a quality issue.","sourceRole":"PRIMARY","verifiedAt":"2026-09-15T00:00:00","supportsText":"Microsoft's audio classifier thresholds, cited as one vendor's thresholds: an audio stream is marked Poor when Packet Utilization exceeds 500 packets and Round Trip is above 500, Packet Loss Rate is above 0.1, or Jitter is above 30 ms. Also carries Microsoft's caveat that a Poor mark does not mean t","domain":"learn.microsoft.com","publisherName":"Microsoft Learn (vendor product documentation, page dated June 16, 2026)"},{"title":"Dimensions and measurements - Call Quality Dashboard (CQD)","url":"https://learn.microsoft.com/en-us/microsoftteams/dimensions-and-measures-available-in-call-quality-dashboard","excerpt":null,"quoteText":"Average packet loss rate for stream. Values grouped by range. 0.1 indicates 10% packet loss.","sourceRole":"PRIMARY","verifiedAt":"2026-09-15T00:00:00","supportsText":"Establishes that a CQD Packet Loss Rate of 0.1 indicates 10 percent packet loss, that Round Trip is the average network propagation round-trip time computed as specified in RFC 3550, and defines Ratio Concealed Samples Avg as the ratio of audio frames containing samples generated by packet loss conc","domain":"learn.microsoft.com","publisherName":"Microsoft Learn"},{"title":"Prepare your organization's network for Teams","url":"https://learn.microsoft.com/en-us/microsoftteams/prepare-network","excerpt":null,"quoteText":"Calls have static and cut out, or voices sound like robots (could be jitter or packet loss).","sourceRole":"PRIMARY","verifiedAt":"2026-09-15T00:00:00","supportsText":"Microsoft's symptom-to-cause hints (dropped calls attributed to firewall or proxy blockers; static, cut-outs and robot voices attributed to jitter or packet loss), the split-tunnel VPN recommendation with its stated reasons including hairpinning that adds latency and jitter, the instruction to keep ","domain":"learn.microsoft.com","publisherName":"Microsoft Learn"},{"title":"Implement Quality of Service (QoS) in Microsoft Teams","url":"https://learn.microsoft.com/en-us/microsoftteams/qos-in-teams","excerpt":null,"quoteText":"For QoS to be effective, you must apply consistent QoS settings throughout your organization. Any part of the path that fails to support your QoS priorities can degrade the quality of calls.","sourceRole":"PRIMARY","verifiedAt":"2026-09-15T00:00:00","supportsText":"Establishes that consistent QoS settings must be applied throughout the organization and that any part of the path failing to support your QoS priorities can degrade call quality, and gives Microsoft's recommended initial DSCP marking for Teams audio as 46, Expedited Forwarding.","domain":"learn.microsoft.com","publisherName":"Microsoft Learn"},{"title":"Modify Bandwidth Consumption Calculation for Voice Calls","url":"https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html","excerpt":null,"quoteText":"40 bytes for IP (20 bytes) / User Datagram Protocol (UDP) (8 bytes) / Real-Time Transport Protocol (RTP) (12 bytes) headers","sourceRole":"PRIMARY","verifiedAt":"2026-09-15T00:00:00","supportsText":"One vendor's per-call arithmetic, used for the capacity row and the packet-loss conversion: 87.2 kbps per direction for G.711 over Ethernet and 31.2 kbps for G.729, from 40 bytes of IP (20), UDP (8) and RTP (12) headers, at 50 packets per second with a 20 ms payload interval. Returned HTTP 403 to cu","domain":"cisco.com","publisherName":"Cisco"},{"title":"Quality of Service Guidelines","url":"https://support.ringcentral.com/sg/en/network-and-system-requirements/network-requirements/overview/quality-of-service-guidelines.html","excerpt":null,"quoteText":"Delay: < 150 ms (one-way). This translates to <300ms round-trip latency. Packet Loss: < 1%. Jitter: < 30 ms.","sourceRole":"PRIMARY","verifiedAt":"2026-09-15T00:00:00","supportsText":"One provider's published end-to-end design targets, cited as that provider's planning values: delay under 150 ms one-way, translated by RingCentral to under 300 ms round trip; packet loss under 1 percent; jitter under 30 ms. Also gives RingCentral's DSCP scheme of 46 (EF) for VoIP media, 34 (AF41) f","domain":"support.ringcentral.com","publisherName":"RingCentral"},{"title":"Implementing Quality of Service for Zoom Phone","url":"https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0076072","excerpt":null,"quoteText":"round-trip delays should not exceed 300ms to ensure optimal performance","sourceRole":"PRIMARY","verifiedAt":"2026-09-15T00:00:00","supportsText":"A second provider's planning value, cited as that provider's: round-trip delays should not exceed 300 ms. Also gives Zoom's Windows client DSCP values of 56 for Zoom Phone media and 40 for signaling, and Zoom's statement that DSCP markings are typically not preserved once traffic leaves the customer","domain":"support.zoom.com","publisherName":"Zoom"},{"title":"Zoom Support response times","url":"https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0059100","excerpt":null,"quoteText":"These are business targets as part of the standard operating procedures. There are no commitments to the engagement or duration of an individual Access support ticket.","sourceRole":"PRIMARY","verifiedAt":"2026-09-15T00:00:00","supportsText":"The single labeled example of provider response targets: Access level support P1 Urgent 4 hours and P2 High 8 hours with P3 and P4 on business days only; Premier level support P1 Urgent 1 hour, P2 High 4 hours, P3 and P4 next business day. Also supports the qualification that the Access figures are ","domain":"support.zoom.com","publisherName":"Zoom"},{"title":"Audio issues - The user experiences echo during the call","url":"https://learn.microsoft.com/en-us/azure/communication-services/resources/troubleshooting/voice-video-calling/audio-issues/echo-issue","excerpt":null,"quoteText":"Currently, if the browser fails to remove echoes, there is no simple way to detect this issue from the information reported by the browser.","sourceRole":"PRIMARY","verifiedAt":"2026-09-15T00:00:00","supportsText":"The acoustic echo mechanism (the microphone picks up sound from the speakers, creating a loop), why echo cancellation fails when the delay between echo and reference signal falls outside the filter's range, the remote-desktop and two-devices-in-one-room scenarios, the statement that there is no simp","domain":"learn.microsoft.com","publisherName":"Microsoft Learn"},{"title":"Network - Disable SIP ALG on a D-Link Router","url":"https://support.ringcentral.com/article-v2/How-to-disable-Sip-ALG-on-a-D-link-Router.html?brand=RC_US&product=RingEX&language=en_US","excerpt":null,"quoteText":null,"sourceRole":"SUPPORTING","verifiedAt":"2026-09-15T00:00:00","supportsText":"A provider support article instructing customers to disable SIP ALG on the router to address one-way audio and audio quality issues. Vendor support material, cited as that provider's instruction rather than independent evidence about ALG behavior in general.","domain":"support.ringcentral.com","publisherName":"RingCentral"},{"title":"RFC 3264: An Offer/Answer Model with the Session Description Protocol (SDP)","url":"https://www.rfc-editor.org/rfc/rfc3264.txt","excerpt":null,"quoteText":"If the answerer has no media formats in common for a particular offered stream, the answerer MUST reject that media stream by setting the port to zero. If there are no media formats in common for all streams, the entire offered session is rejected.","sourceRole":"INDEPENDENT","verifiedAt":"2026-09-15T00:00:00","supportsText":"Establishes that codec mismatch is a setup failure and not an audio-quality problem: an answerer with no media formats in common must reject that stream by setting the port to zero, and the entire offered session is rejected when no stream has a format in common.","domain":"rfc-editor.org","publisherName":"IETF"},{"title":"RFC 8445: Interactive Connectivity Establishment (ICE)","url":"https://www.rfc-editor.org/rfc/rfc8445.txt","excerpt":null,"quoteText":"Protocols establishing communication sessions between peers typically involve exchanging IP addresses and ports for the data sources and sinks. However, this poses challenges when operated through Network Address Translators (NATs).","sourceRole":"INDEPENDENT","verifiedAt":"2026-09-15T00:00:00","supportsText":"Establishes that NAT is the documented obstacle when two peers exchange the IP addresses and ports for a direct data flow, which is the mechanism behind one-way audio on a call whose signaling succeeded.","domain":"rfc-editor.org","publisherName":"IETF"},{"title":"RFC 5853: Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments","url":"https://www.rfc-editor.org/rfc/rfc5853.txt","excerpt":null,"quoteText":null,"sourceRole":"INDEPENDENT","verifiedAt":"2026-09-15T00:00:00","supportsText":"Establishes that signaling and media are handled as separate flows by session border controllers, that SBCs perform NAT traversal by relaying media, and that the NAT traversal function keeps NAT bindings alive with control traffic, which is the mechanism behind calls that drop when a binding expires","domain":"rfc-editor.org","publisherName":"IETF"}],"revisions":[{"revisedAt":"2026-06-15T14:28:52.18+00:00","versionLabel":"Originally published","note":"","reviewedBy":null}],"relatedAnswers":[{"id":"f7b5d5d8-aadd-4135-b31d-5ff0dbbf934e","slug":"what-ucaas-deployment-model-suits-enterprises-with-hybrid-infrastructure","question":"What UCaaS deployment model suits enterprises with hybrid infrastructure?","publishedAt":"2026-09-27T14:29:18.879","confidenceScore":null,"confidenceLabel":null,"industry":{"id":"ff619d7c-d7d7-485e-a05a-53fba07f33ed","slug":"telecommunications","label":"Telecommunications","description":"Business voice, fiber, UCaaS, and network services"},"topic":{"slug":"ucaas","label":"UCaaS","description":null,"schemaKind":null},"contributor":{"id":"ec39deab-44fe-48d8-9029-fefe993ab85a","slug":"answer-stack","displayName":"AnswerStack","websiteUrl":null},"snippet":"For an enterprise with hybrid infrastructure, we'd recommend cloud call control, with equipment kept on site only where a named system, contract or outage requirement needs it. Coexistence, media routing and survivability are separate choices, shown with Teams Direct Routing and, as a separate service, Atlantech's hosted lines.","url":"/q/what-ucaas-deployment-model-suits-enterprises-with-hybrid-infrastructure"},{"id":"790feafe-8a6a-45e3-a954-23056b271d9a","slug":"how-does-ucaas-compare-to-on-premises-pbx","question":"How does UCaaS compare to on-premises PBX?","publishedAt":"2026-09-07T19:54:51.173","confidenceScore":null,"confidenceLabel":null,"industry":{"id":"ff619d7c-d7d7-485e-a05a-53fba07f33ed","slug":"telecommunications","label":"Telecommunications","description":"Business voice, fiber, UCaaS, and network services"},"topic":{"slug":"ucaas","label":"UCaaS","description":null,"schemaKind":null},"contributor":{"id":"ec39deab-44fe-48d8-9029-fefe993ab85a","slug":"answer-stack","displayName":"AnswerStack","websiteUrl":null},"snippet":"UCaaS and an on-premises PBX do the same calling job in different places. A PBX is equipment at your site that your team or a contractor maintains. UCaaS runs in the provider's cloud for a per-user monthly fee and adds video, chat and mobile apps. Cost, upkeep, outage exposure and control of data all follow from that difference, and a business can keep its PBX while changing the service that feeds it.","url":"/q/how-does-ucaas-compare-to-on-premises-pbx"},{"id":"62173c10-e3cc-4a28-bec3-67d899f7f24f","slug":"how-do-you-evaluate-ucaas-providers-before-buying","question":"How do you evaluate UCaaS providers before buying?","publishedAt":"2026-09-03T14:28:51.344","confidenceScore":86,"confidenceLabel":"High","industry":{"id":"ff619d7c-d7d7-485e-a05a-53fba07f33ed","slug":"telecommunications","label":"Telecommunications","description":"Business voice, fiber, UCaaS, and network services"},"topic":{"slug":"ucaas","label":"UCaaS","description":null,"schemaKind":null},"contributor":{"id":"ec39deab-44fe-48d8-9029-fefe993ab85a","slug":"answer-stack","displayName":"AnswerStack","websiteUrl":null},"snippet":"Evaluate a UCaaS provider in three passes: rule out providers that fail a fixed requirement, compare the rest on written price, term and service terms, then test your own call flow on your own equipment before signing.","url":"/q/how-do-you-evaluate-ucaas-providers-before-buying"},{"id":"a94ef24e-8f5b-40e8-9b5d-ec273215a8c8","slug":"what-ucaas-compliance-requirements-apply-to-healthcare-organizations","question":"What UCaaS compliance requirements apply to healthcare organizations?","publishedAt":"2026-08-25T14:28:52.466","confidenceScore":null,"confidenceLabel":null,"industry":{"id":"ff619d7c-d7d7-485e-a05a-53fba07f33ed","slug":"telecommunications","label":"Telecommunications","description":"Business voice, fiber, UCaaS, and network services"},"topic":{"slug":"ucaas","label":"UCaaS","description":null,"schemaKind":null},"contributor":{"id":"ec39deab-44fe-48d8-9029-fefe993ab85a","slug":"answer-stack","displayName":"AnswerStack","websiteUrl":null},"snippet":"In the United States, HIPAA sets the main requirements. A covered entity using UCaaS has to include it in its Security Rule risk analysis and safeguards, and needs a business associate agreement before using features that store patient information, such as voicemail, recordings and transcripts. HHS's Office for Civil Rights doesn't endorse or certify products.","url":"/q/what-ucaas-compliance-requirements-apply-to-healthcare-organizations"}],"contributorStats":{"verifiedAnswers":149,"openDisputes":0},"schemaJson":{"@context":"https://schema.org","@type":"Question","name":"What are common UCaaS call quality problems?","text":"What are common UCaaS call quality problems?","url":"https://www.answerstack.io/q/what-are-common-ucaas-call-quality-problems","answerCount":1,"datePublished":"2026-08-11T14:28:52.18","about":[{"@type":"Thing","name":"UCaaS"},{"@type":"Thing","name":"Telecommunications"}],"acceptedAnswer":{"@type":"Answer","text":"The call quality problems people report on a UCaaS service come down to a handful of things you can hear: voices that break up or sound robotic, calls that drop, a lag that has two people talking over each other, echo, and calls where one side hears nothing. Each of them has more than one plausible cause. Some causes sit in the network between the user and the provider, and others sit in a headset, a laptop or the room. So the first job is to work out who and what is affected, and only then to decide what to fix.","url":"https://www.answerstack.io/q/what-are-common-ucaas-call-quality-problems","upvoteCount":0,"datePublished":"2026-08-11T14:28:52.18","dateModified":"2026-09-14T00:00:00","citation":[{"@type":"CreativeWork","name":"ITU-T G.114: One-way transmission time","url":"https://www.itu.int/rec/T-REC-G.114/en"},{"@type":"CreativeWork","name":"Understanding Delay in Packet Voice Networks","url":"https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/5125-delay-details.html"},{"@type":"CreativeWork","name":"RFC 3550: RTP: A Transport Protocol for Real-Time Applications","url":"https://www.rfc-editor.org/rfc/rfc3550.txt"},{"@type":"CreativeWork","name":"RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control","url":"https://www.rfc-editor.org/rfc/rfc3551.txt"},{"@type":"CreativeWork","name":"RFC 5481: Packet Delay Variation Applicability Statement","url":"https://www.rfc-editor.org/rfc/rfc5481.txt"},{"@type":"CreativeWork","name":"Stream classification in Call Quality Dashboard (CQD)","url":"https://learn.microsoft.com/en-us/microsoftteams/stream-classification-in-call-quality-dashboard"},{"@type":"CreativeWork","name":"Dimensions and measurements - Call Quality Dashboard (CQD)","url":"https://learn.microsoft.com/en-us/microsoftteams/dimensions-and-measures-available-in-call-quality-dashboard"},{"@type":"CreativeWork","name":"Prepare your organization's network for Teams","url":"https://learn.microsoft.com/en-us/microsoftteams/prepare-network"},{"@type":"CreativeWork","name":"Implement Quality of Service (QoS) in Microsoft Teams","url":"https://learn.microsoft.com/en-us/microsoftteams/qos-in-teams"},{"@type":"CreativeWork","name":"Modify Bandwidth Consumption Calculation for Voice Calls","url":"https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html"},{"@type":"CreativeWork","name":"Quality of Service Guidelines","url":"https://support.ringcentral.com/sg/en/network-and-system-requirements/network-requirements/overview/quality-of-service-guidelines.html"},{"@type":"CreativeWork","name":"Implementing Quality of Service for Zoom Phone","url":"https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0076072"},{"@type":"CreativeWork","name":"Zoom Support response times","url":"https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0059100"},{"@type":"CreativeWork","name":"Audio issues - The user experiences echo during the call","url":"https://learn.microsoft.com/en-us/azure/communication-services/resources/troubleshooting/voice-video-calling/audio-issues/echo-issue"},{"@type":"CreativeWork","name":"Network - Disable SIP ALG on a D-Link Router","url":"https://support.ringcentral.com/article-v2/How-to-disable-Sip-ALG-on-a-D-link-Router.html?brand=RC_US&product=RingEX&language=en_US"},{"@type":"CreativeWork","name":"RFC 3264: An Offer/Answer Model with the Session Description Protocol (SDP)","url":"https://www.rfc-editor.org/rfc/rfc3264.txt"},{"@type":"CreativeWork","name":"RFC 8445: Interactive Connectivity Establishment (ICE)","url":"https://www.rfc-editor.org/rfc/rfc8445.txt"},{"@type":"CreativeWork","name":"RFC 5853: Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments","url":"https://www.rfc-editor.org/rfc/rfc5853.txt"}]}}}