在 Microsoft 團隊中使用 CQD 管理通話與會議品質Use CQD to manage call and meeting quality in Microsoft Teams

這篇文章將協助您使用 Microsoft 團隊通話品質儀表板 (CQD) ,協助您的團隊管理員或支援人員或技術支援人員。This article will help you - the Teams admin or support and helpdesk engineer - to develop a process for monitoring and maintaining call and meeting quality for your organization by using Microsoft Teams Call Quality Dashboard (CQD). 我們的指導方針會強調音訊品質案例,因為您針對改善音訊體驗所做的任何網路改進都會轉化為影片和共用的改良功能。Our guidance emphasizes audio-quality scenarios because any network improvements you make to improve the audio experience will translate to improvements in video and sharing.

本指南的主要內容是兩個策劃 CQD 範本,我們建議您先下載它們,然後再逐步閱讀本文中的指導方針。Key to this guidance are the two curated CQD templates - we recommend that you download them before you go through the guidance in this article.

本文假設您已設定 CQDThis article assumes that you've already set up CQD.

要監視及維護的類別Categories to monitor and maintain

當您在小組中推出會議和語音功能之後,您將需要進行持續監視及維護的方案。Once you've rolled out meetings and voice in Teams, you'll need a plan for ongoing monitoring and maintenance. 如此一來,就能確保團隊總是以最佳的方式運作。Doing so will ensure that Teams is always running optimally. 此方案應包含下列主要區域。This plan should include the key areas listed below. 您也應該針對品質度量建立目標,以及在問題發生時進行疑難排解及隔離問題的方案。You should also establish targets for quality metrics and a plan for troubleshooting and isolating problems when they happen.

類別Category 描述Description
通話品質Call quality

在您的組織內將度量單位細分為 (內部呼叫,例如 VPN、WiFi、有線) 或外部通話Break down the metrics by internal calls (within your organization, such as VPN, WiFi, wired) or external calls

透過組建或網路細分度量標準Break down the metrics by building or network

VPN 通話VPN calls

使用 TCP、UDP 或 proxy 的通話Calls using TCP, UDP, or proxy

通話可靠性Call reliability

找出並修正任何網路或防火牆問題Identify and remediate any network or firewall problems

深入瞭解通話設定與丟單失敗百分比Gain insights into the percentages of call setup and drop failures

瞭解大部分的撥號設定與丟單失敗發生的位置Learn where the majority of call setup and drop failures occur

使用者問卷User survey

使用費率給我的通話資料打分,瞭解使用者的實際體驗Use Rate My Call data to learn about users' actual experience

較差的體驗在哪裡?Where are the poor experiences occurring?

將較差的體驗與通話品質、可靠性和裝置產生關聯Correlate the poor experience with call quality, reliability, and devices

裝置Devices

瞭解哪些麥克風和喇叭最常使用,以及它們對通話品質的影響Learn which microphones and speakers are most commonly used and their impact on call quality

是否要定期修補支援音訊、影片、USB 及 WiFi 驅動程式?Are the supporting audio, video, USB, and WiFi drivers being regularly patched?

Clients

瞭解使用哪些用戶端類型和版本,以及它們對通話品質與可靠性的影響Learn which client types and versions are being used and their impact on call quality and reliability

透過連續評估與修正本文所述的區域,您可以減少對使用者造成負面影響的可能性。By continually assessing and remediating the areas described in this article, you can reduce their potential to negatively affect your users. 大多數的使用者問題都可以分為下列類別:Most user problems can be grouped into the following categories:

  • 防火牆或 proxy 配置不完整Incomplete firewall or proxy configuration
  • 低 wi-fi 覆蓋範圍Poor Wi-Fi coverage
  • 頻寬不足Insufficient bandwidth
  • 點對點VPN
  • 用戶端版本與驅動程式不一致或過時Inconsistent or outdated client versions and drivers
  • 未優化或內建音訊裝置Unoptimized or built-in audio devices
  • 有問題的子網或網路裝置Problematic subnets or network devices

在部署團隊或商務用 Skype Online 前,請先進行適當的規劃與設計,您就可以減少維持高品質體驗所需的工作量。Through proper planning and design before deploying Teams or Skype for Business Online, you can reduce the amount of effort that will be required to maintain high-quality experiences.

本文主要是使用 [通話品質] 儀表板 (CQD) Online 做為主要工具來報告並調查每個區域,在音訊上特別強調最大化採納與影響。This article focuses on using the Call Quality Dashboard (CQD) Online as the primary tool to report and investigate each area, with a special emphasis on audio to maximize adoption and impact. 針對改善音訊體驗的網路所做的任何改善,也會直接翻譯成影片與桌面共用的改良功能。Any improvements made to the network to improve the audio experience will also directly translate to improvements in video and desktop sharing.

為加速您的評估,提供兩個策劃 CQD 範本:一個用於管理所有網路,而另一個則只針對內部) 網路的管理 (進行篩選。To accelerate your assessment, two curated CQD templates are provided: one is for managing all networks and the other is filtered for managed (internal) networks only. 雖然所有網路範本報告都設定為顯示建立和網路資訊,但是當您在收集與上傳資訊時,仍然可以使用它們。Although the All Networks template reports are configured to display building and network information, they can still be used while you work toward collecting and uploading building information. 將組建資訊上傳到 CQD,可讓服務在與外部子網區分內部的同時,透過新增自訂的建築物、網路和位置資訊來加強報告。Uploading building information into CQD enables the service to enhance reporting by adding custom building, network, and location information while differentiating internal from external subnets. 如需詳細資訊,請參閱建立對應For more information, read Building mapping.

目標物件Intended audience

本文旨在供合作夥伴與客戶的相關人員使用,包括共同作業主管/架構師、顧問、變更管理/採用專家、網路組長、桌面組長及 IT 系統管理員等角色。This article is intended to be used by partner and customer stakeholders with roles such as Collaboration Lead/Architect, Consultant, Change Management/Adoption Specialist, Support/Help Desk Lead, Network Lead, Desktop Lead, and IT Admin.

本文也適用于指定品質擁護者 (s) 。This article is also intended to be used by the designated quality champion(s). 如需詳細資訊,請參閱品質擁護者角色For more information, see the Quality Champion role.

什麼是品質?What is quality?

在這種情況下,品質是服務衡量標準與使用者經驗的結合。In this context, quality is a combination of service metrics and user experience.

服務度量單位Service metrics

服務度量單位是由特定的用戶端測量標準所組成。Service metrics consist of specific client-based metrics. 在每次通話期間,用戶端會收集通話的遙測,並在每次通話結束時提交報告,以便在 CQD 或每個使用者的呼叫分析中存取。During each call, the client collects telemetry for the call and submits a report at the end of each call that can later be accessed in CQD or in per-user call analytics. 這些度量單位包括 (但不限於) :These metrics include (but aren't limited to):

  • 傳入及傳出) 的資料流程 (不佳Poor Stream (incoming and outgoing)
  • 設定失敗率Setup Failure Rate
  • 丟單失敗率Drop Failure Rate

較差的串流速率Poor stream rate

較差的串流速率 (PSR.EXE) 代表組織中品質較差的資料流程總百分比。The poor stream rate (PSR) represents the organization's overall percentage of streams that have poor quality. 這個指標是要醒目提示貴組織在哪些區域中,您的組織能專注于減少此值並改善使用者體驗等最大的影響,這就是為什麼在查看 PSR.EXE 時, managed 網路是主要的焦點。This metric is meant to highlight areas where your organization can concentrate effort to have the strongest impact toward reducing this value and improving the user experience, which is why managed networks are the primary focus when looking at PSR. 外部使用者也很重要,但調查會因組織而異。External users are important too, but investigation differs on an organizational basis. 考慮為外部使用者提供最佳做法,並獨立于整體組織調查外部通話。Consider providing best practices for external users, and investigate external calls independently from the overall organization.

CQD 中的實際度量單位依工作量而異,但在本文中,我們主要將重點放在_音訊不佳的百分比_測量中。The actual measurement in CQD varies by workload, but for the purposes of this article, we focus primarily on the Audio Poor Percentage measurement. PSR.EXE 是由下表所述的五個網路度量值所組成。PSR is made up of the five network metric averages described in the following table. 針對要分類為較差的資料流程,只有一個公制需要超過定義的閾值。For a stream to be classified as poor, only one metric needs to exceed the defined threshold. CQD 提供「不佳的原因 ...」測量,以更清楚地瞭解哪個條件導致資料流程分類為較差。CQD provides the "Poor Due To…" measurements to better understand what condition caused the stream to be classified as poor. 若要深入瞭解,請參閱CQD 中的資料流程分類To learn more, read Stream classification in CQD.

注意

CQD 提供「不佳的原因 ...」測量,以更清楚地瞭解哪個條件導致資料流程分類為較差。CQD provides the "Poor due to…" measurements to better understand what condition caused the stream to be classified as poor.

音訊品質不佳的指標Audio poor quality metrics
公制平均值Metric average 描述Description 使用者體驗User experience
抖動 > 30 毫秒Jitter >30 ms 這是連續資料包之間延遲的平均變更。This is the average change in delay between successive packets. 團隊和商務用 Skype 可透過緩衝來適應某些層級的抖動。Teams and Skype for Business can adapt to some levels of jitter through buffering. 只有抖動超過參與者通知抖動效果的緩衝時才是如此。It's only when the jitter exceeds the buffering that a participant notices the effects of jitter. 以不同速度傳入的資料包會導致演講者的語音音效機器人。The packets arriving at different speeds cause a speaker's voice to sound robotic.
資料包遺失率 > 10% 或0。1Packet loss rate >10% or 0.1 這通常會定義為遺失的資料包百分比。This is often defined as a percentage of packets that are lost. 資料包遺失會直接影響音訊品質-從較小、個別的遺失包,這些資料包幾乎不會影響到導致音訊完全剪下的後置脈衝損失。Packet loss directly affects audio quality—from small, individual lost packets that have almost no impact to back-to-back burst losses that cause audio to cut out completely. 丟棄且未送達預期目的地的資料包會引起媒體中的差距,導致不想要的音節與單字,以及不連貫的影片和共用。The packets being dropped and not arriving at their intended destination cause gaps in the media, resulting in missed syllables and words, and choppy video and sharing.
雙程時間 > 500 msRound-trip time >500 ms 這是取得從 A 指向點 B 並回到點 A 的 IP 資料包所需的時間。此網路傳播延遲會與兩個點之間的物理距離和光線速度之間的距離相關,並包括網路路徑中各種裝置所佔用的額外額外負荷。This is the time it takes to get an IP packet from point A to point B and back to point A. This network propagation delay is tied to the physical distance between the two points and the speed of light, and includes additional overhead taken by the various devices in the network path. 資料包太長而無法送達目的地會導致 walkie talkie 的效果。The packets taking too long to arrive at their destination cause a walkie-talkie effect.
NMOS 下降平均值 > 1。0NMOS degradation average >1.0 (NMOS 資料流程) 下降的平均網路平均觀念分數Average Network Mean Opinion Score (NMOS) degradation for the stream. 代表網路遺失和抖動對導致 NMOS 下降的音訊品質有多大的影響。Represents how much the network loss and jitter has affected the quality of received audio that caused the NMOS to drop by more than one point. 這會結合抖動、資料包遺失,以及較低的程度,增加往返時間。This is a combination of jitter, packet loss, and—to a lesser degree—increased round-trip time. 使用者可能會遇到這些問題的組合。The user might be experiencing a combination of these symptoms.
隱藏樣本 > 7% 或0.07 的平均比率Average ratio of concealed samples >7% or 0.07 音訊幀數的平均比率,由資料包遺失修複產生的隱藏範例,到音訊畫面總數目。Average ratio of the number of audio frames with concealed samples generated by packet loss healing to the total number of audio frames. 隱藏的音訊範例是一種技術,用來平滑通常是由網路資料包所造成的突然轉場。A concealed audio sample is a technique used to smooth out the abrupt transition that would usually be caused by dropped network packets. [高值] 表示已套用大量的 [損失 concealment],並產生扭曲或遺失的音訊。High values indicate that significant levels of loss concealment were applied and resulted in distorted or lost audio.
為什麼我們想要使用串流而不是通話?Why do we prefer to use streams instead of calls?

資料流程可讓我們知道來電的哪個特定腿不佳-外寄或撥入。Streams let us know which particular leg of the call was poor - outgoing or incoming. 當您要查看通話分析是否有不佳的通話時,請判斷呼叫者的資料流程 (輸出) 或被叫方資料流程 (入站) 。When you're looking at call analytics for a poor call, determine whether the poor call was due to that caller's stream (outbound) or callee's stream (inbound). 判斷哪些資料流程會影響通話品質,對於會議而言甚至更加重要。Determining which stream is impacting call quality is even more important for conferences. 如果您只是查看通話資料,您會看到某人參與了多少會議,但您不會看到哪些人是使用中的喇叭,但卻看不到您的螢幕共用。If you're only looking at call data, you'll see how many conferences a person participates in, but you won't see which people are active speakers, doing the most screen sharing.

通話資料可提供使用方式指標,但不一定會將您引導至無法正常通話品質的根本原因。Call data gives you usage metrics, but it won't necessarily lead you to the root cause for poor call quality. 透過查看資料流程方向,您可以找出不在受管理網路上的通話數、非員工 ((例如,供應商或其他) 網路上的人員)的呼叫。By looking at stream direction, you can identify factors such as a call that's not on a managed network, a call from a non-employee (e.g., a vendor or someone on a different network). 在這些情況下,如果其他人的網路連線較差,整個通話都會標示為不佳。In these cases, if the other person's network connection was poor, the entire call will be flagged as poor. 您無法對外部因素執行任何動作,所以這個資料並不是很有説明的。You can't do anything about external factors, so this data isn't helpful.

資料流程方向也可協助您找出有問題的裝置或用戶端。Stream direction can also help you identify problematic devices or clients.

  • 例如,如果您的裝置預算有限,且想要為大量音訊使用者提供裝置,請使用 [音訊使用量報告] (VoIP) ,然後篩選出站資料流程與會議。For example, If you have a limited budget for devices and want to provide devices only for heavy audio users, use the audio usage report (VoIP) and filter for outbound streams and conferencing. 尋找在內建麥克風說話的大量音訊使用者-這些專案可能會與較差的通話品質 (,而且您可能會想要為這些人) 提供音訊裝置。Look for high-volume audio users who are speaking into built-in microphones - these may correlate to poorer call quality (and you might want to provide audio devices for these people). 為了更清楚起見,您可以篩選資料包利用率,讓您針對特別高容量的音訊使用者進行設定。For added clarity, you could filter for packet utilization, which will let you target especially high-volume audio users.

  • 另一個範例涉及螢幕共用。Another example involves screen sharing. 如果客戶使用舊的團隊用戶端,螢幕共用效能可能會受到影響。If a customer is using an old Teams client, screen sharing performance may be affected. 您可以針對完成許多螢幕共用的人員,為用戶端升級劃分優先順序,以解決這個問題。You could address this problem by prioritizing client upgrades for people who do a lot of screen sharing.

  • 透過找出資料流程的哪個方向造成不佳的通話品質,您可以判斷您是否有與 QoS 或頻寬相關的問題。By identifying which direction of a stream is causing poor call quality, you can determine whether you've got a QoS or bandwidth-related problem. 如果您尚未完全實現 QoS,或者您只在用戶端(而不是在輸入資料流程)標示資料包,您可能會看到較差的通話品質。If you haven't fully implemented QoS, or if you only mark packets at the client and not at the inbound stream, you might see poorer call quality. 透過查看資料流程方向,您可以更精確地查看資料包遺失、延遲或抖動的特定方向。By looking at stream direction, you can get a more granular view of packet loss, latency, or jitter in a specific direction.

    • 例如,假設您在有線連線 (抖動) 中,讓使用者 complains 機器人音訊。For example, let's say a user complains of robotic audio while on a wired connection (jitter). 透過查看資料流程和方向,您可以判斷問題只會出現在進貨資料流程上,只適用于一組特定的子網。By looking at stream and direction, you can determine that the problem happens on the inbound stream, only for a specific set of subnets. 在您將此資訊提供給您的網路小組之後,他們就能向下追蹤,找出無法繞過媒體流量的錯誤配置 WAN 加速器。After you give this information to your networking team, they can track it down to a misconfigured WAN accelerator that was not bypassing media traffic. 網路小組重新配置 WAN 加速器之後,抖動就會消失,並改善通話品質。Once the network team reconfigures the WAN accelerator, jitter disappears and call quality improves.

設定失敗率Setup Failure Rate

設定失敗率(亦即在 CQD 中的_呼叫設定失敗百分比_測量)是在通話開始時端點之間無法建立媒體路徑的串流數。The setup failure rate, otherwise known as the Total Call Setup Failure Percentage measurement in CQD, is the number of streams where the media path couldn't be established between the endpoints at the start of the call.

這代表無法建立的任何媒體資料流程。This represents any media stream that couldn't be established. 考慮到這個問題對使用者經驗造成影響的嚴重性,目標是將這個值縮小至盡可能接近零。Given the severity of the impact of this problem on the user experience, the goal is to reduce this value to as close to zero as possible. 這個指標的高值在新部署中的防火牆規則不完整的情況下比較常見,但請務必定期觀看。A high value for this metric is more common in new deployments with incomplete firewall rules than a mature deployment, but it's still important to watch on a regular basis.

這個指標是透過以下方式來計算:根據在 CDR) 中提交成功呼叫詳細資料 (記錄的總串流數來進行設定失敗的總串流數:This metric is calculated by taking the total number of streams that failed to set up divided by the total number of streams that submitted a successful call detail record (CDR):

  • 設定失敗率= 總的通話設定失敗資料流程計數/總 CDR 可用資料流程計數Setup Failure Rate = Total Call Setup Failed Stream Count / Total CDR Available Stream Count

丟單失敗率Drop Failure Rate

在 CQD 中,擊落失敗率(亦稱為 [總呼叫中斷失敗百分比])是已成功建立的資料流程在媒體路徑無法正常終止的百分比。The drop failure rate, otherwise known as the Total Call Dropped Failure Percentage measurement in CQD, is the percentage of successfully established streams where the media path didn't terminate normally.

這代表任何意外終止的媒體資料流程。This represents any media stream that terminated unexpectedly. 雖然這種影響並非與設定失敗的資料流程一樣嚴重,但仍會對使用者體驗造成負面影響。Although the impact of this isn't as severe as a stream that failed to set up, it still negatively affects the user experience. 突然且頻繁的媒體跌落不只會對使用者體驗產生嚴重影響,因此它們會導致使用者需要重新連線,導致生產率損失 (不會提及不滿) 。Sudden and frequent media drops not only can have a severe impact on the user experience, they result in the need for users to reconnect, resulting in lost productivity (not to mention frustration).

指標的計算方式為:將丟棄的資料流程總數除以已成功設定的資料流程總計數:The metric is calculated by taking the total number of dropped streams divided by the total count of streams that set up successfully:

  • 丟單失敗率= 總的呼叫中斷串流總數/總呼叫設定成功的資料流程計數Drop Failure Rate = Total Call Dropped Stream Count / Total Call Setup Succeeded Stream Count

定義您的目標度量Define your target metrics

本節討論我們用來評估服務健康情況的一些核心服務度量單位。This section discusses some of the core service metrics that we use to assess the health of the services. 若要不斷地評估並推動努力,將這些測量標準放在其定義的目標之下,您將有助於確保您的使用者體驗一致且可靠的通話品質。By continually assessing and driving efforts to keep these metrics below their defined targets, you'll help ensure that your users experience consistent, reliable call quality. 在起始點,請使用下表中的建議目標。As a starting point, use the suggested targets in the table below. 視需要調整目標,以符合您的業務目標。Adjust the targets as needed to meet your business objectives.

網路類型Network type品質目標Quality targets可靠性目標Reliability targets
音訊低劣的資料流程速度Audio Poor Stream Rate設定失敗率Setup Failure Rate丟單失敗率Drop Failure Rate
\* AllAll內部Internal2.0%2.0%0.5%0.5%2.0%2.0%
全域Overall3.0%3.0%1.0%1.0%3.0%3.0%
會議Conferencing內部Internal2.0%2.0%0.5%0.5%2.0%2.0%
有線內部Wired internal1.0%1.0%0.5%0.5%1.0%1.0%
Wi-fi 5 GHz 內部Wi-Fi 5 GHz internal1.0%1.0%0.5%0.5%1.0%1.0%
Wi-fi 2.4 GHz 內部Wi-Fi 2.4 GHz internal2.0%2.0%0.5%0.5%2.0%2.0%
全域Overall2.0%2.0%0.5%0.5%3.0%3.0%
P2PP2P內部Internal2.0%2.0%0.5%0.5%2.0%2.0%
有線/Wi-fi 5 GHz 內部Wired/Wi-Fi 5 GHz internal1.0%1.0%0.5%0.5%1.0%1.0%
有線/Wi-fi 5 GHz 整體Wired/Wi-Fi 5 GHz overall2.0%2.0%1.0%1.0%1.0%1.0%
全域Overall2.0%2.0%1.0%1.0%3.0%3.0%

使用者體驗User experience

分析使用者體驗的美工圖案比科學更多,因為這裡收集的度量單位並不一定代表網路或服務發生問題,而是只指示使用者感覺問題。Analyzing the user experience is more art than science, because the metrics gathered here don't always mean that there's a problem with the network or service but rather, they simply indicate that the user perceives a problem. CQD 包含內建的調查機制,可讓我的通話 (RMC) ,以協助估量整體使用者經驗。CQD includes a built-in survey mechanism — Rate My Call (RMC) — to help gauge overall user experience. RMC 可讓您深入瞭解使用者對下列問題的觀點:RMC will give you insight into the following questions from the perspective of your users:

  • 我知道如何使用此方案嗎?Do I know how to use the solution?
  • 這個方案便於使用且直觀,而且它支援我的日常通訊需求?Is the solution easy to use and intuitive, and does it support my day-to-day communication needs?
  • 此方案可協助我完成工作嗎?Does the solution help me get my job done?
  • 這個方案的整體認識是什麼?What's my overall perception of the solution?
  • 無論是在何處,都能在任何時間點使用解決方案?Can I use the solution at any point in time, regardless of where I am?
  • 我可以設定及維護通話嗎?Can I set up and maintain a call?

評價我的通話Rate My Call

在小組和商務用 Skype 中建立 RMC) , (的通話費率。Rate My Call (RMC) is built into Teams and Skype for Business. 它會在每10個通話中自動彈出一個,或10%。It automatically pops up after one in every 10 calls, or 10 percent. 此簡短問卷會要求使用者對通話進行評分,並提供一些內容,以瞭解為何通話品質可能較差。This brief survey asks the user to rate the call and provide a little context for why the call quality might have been poor. 一或兩個評等不佳,3到4個是良好的,5是極好的。A one or two rating is considered poor, three to four is good, and five is excellent. 雖然這是延遲指標的一部分,但對於發現服務規格可能遺漏的問題而言,這是一個非常實用的規格。Although it's somewhat of a lagging indicator, this is a useful metric for uncovering issues that service metrics can miss.

注意

人體因數:使用者通常會在通話品質良好時忽略調查,當通話品質不正確時,就會填寫問卷。The human factor: Users often ignore the survey when call quality is good, and they fill it out when call quality is bad. 因此,即使服務衡量標準良好,您的 RMC 報告也可能會在差側扭曲。As a result, your RMC reports might be skewed to the poor side even while service metrics are good.

您可以使用 CQD 來報告 RMC 的使用者回應,並將範例報告包含在 CQD 範本中。You can use CQD to report on RMC user responses, and sample reports are included in the CQD template. 不過,本文不會詳細討論。However, they aren't discussed in detail in this article.

用戶端和裝置準備就緒Client and device readiness

您需要實體用戶端和裝置策略,以協助確保您的使用者擁有一致且積極的使用者體驗。You need a solid client and device strategy to help ensure that your users have a consistent and positive user experience. 幾個主要原則會推動每個準備策略。A few key principles drive each readiness strategy.

用戶端就緒Client readiness

讓團隊用戶端保持在最新狀態,可確保您的使用者永遠能取得最佳的體驗。Keeping the Teams client up-to-date ensures that your users are always getting the best-possible experience. Microsoft 會頻繁發行小組用戶端的更新 (更新會在背景中自行安裝,除非您關閉此功能,但我們不建議) 。Microsoft releases frequent updates to the Teams client (the update installs itself in the background unless you've turned off this functionality - which we don't recommend). 請務必記住修補網路、影片、USB 和音訊驅動程式,因為它們經常被忽視,且可能會影響通話和會議品質。It's also important to remember to patch network, video, USB, and audio drivers, because they're often overlooked and can affect call and meeting quality. 考慮將網路、Wi-fi、影片、USB 和音訊驅動程式新增到您目前的修補程式管理程式。Consider adding network, Wi-Fi, video, USB, and audio drivers to your current patch management process.

裝置就緒Device readiness

任何單一策略都不會影響使用者體驗,而不是您的裝置準備方案。No one single strategy can affect the user experience more than your device readiness strategy. 例如,依賴其膝上型電腦和麥克風的使用者會在通話和會議中遇到許多背景雜音。For example, users who rely on their laptop speakers and microphone will experience a lot of background noise in calls and meetings. 團隊專用於幾乎任何裝置,但如果您有與裝置相關的問題,請參閱手機供團隊使用。Teams is designed to work with almost any device, but if you're having device-related problems, check out Phone for Teams.

品質類別Categories of quality

Operationalize 一組品質管制做法-這可讓您獲得良好通話和會議品質的最佳機會。Operationalize a set of quality-management practices - this gives you the best chance of good call and meeting quality. 優質管理方案會解決下列類別:A good quality management plan addresses these categories:

  • 網路: 注重資料流程比率較差的音訊品質 (PSR.EXE) 公制、TCP 使用量、有線和無線子網上,以及識別 HTTP proxy 與 VPN 的使用Network: Audio quality focused on the Poor Stream Ratio (PSR) metric, TCP usage, wired and wireless subnets, and identifying the use of HTTP proxies and VPN

  • 端點: 音訊裝置和最新用戶端Endpoints: Audio devices and up-to-date clients

  • 服務管理: 此類別包含兩個區段:Service Management: This category comprises two sections:

    • 首先,Microsoft 必須負責管理和維護小組及商務用 Skype Online 服務。First is Microsoft's responsibility to manage and maintain the Teams and Skype for Business Online services.

    • 第二個是貴組織管理的工作,以確保對服務的可靠存取,例如更新建立資訊,並在新的 Office 365 IP 位址中維護防火牆,以將基礎結構新增至服務。Second are tasks your organization manages to ensure reliable access to the service, such as updating building information and maintaining firewalls for new Office 365 IP addresses as infrastructure is added to the service.

組織中品質類別的圖形Graph of the categories of quality in an organization

請查看下列建議的工作清單,以維持品質。Review the following list of tasks recommended to maintain quality. 您應該定期執行這些工作,例如 [每週]。You should perform these tasks regularly - for example, weekly.

服務管理工作Service management tasks

這些工作的範圍包括確保有足夠的頻寬可達到服務,而不需要飽和網際網路連結、驗證服務品質 (QoS) 在所有受管理的網路區域中都已就緒,且在防火牆上保持在Office 365 IP 範圍的最上層。These tasks range from ensuring there is sufficient bandwidth to reach the service without saturating internet links, validating that quality of service (QoS) is in place on all managed network areas, and staying on top of Office 365 IP ranges on firewalls.

網路工作Network tasks

網路任務有兩種類別:可靠性和品質。There are two categories of network tasks: reliability and quality. 可靠性側重于測量使用者成功進行呼叫並保持連線的能力。Reliability focuses on measuring the user's ability to make calls successfully and stay connected. [品質] 主要是在通話期間和結束後,透過使用者用戶端傳送給小組和商務用 Skype Online 的匯總遙測。Quality focuses on the aggregated telemetry sent to Teams and Skype for Business Online by the user's client during the call and after it has ended.

根據可靠性對使用者體驗的重要影響,我們建議您先評估並調查可靠性量度,然後再深入瞭解品質。Given the critical impact that reliability has on the user experience, we recommend that you assess and investigate reliability metrics before you dive into quality.

端點任務Endpoints tasks

此類別中的主要工作會移除一般小組用戶端更新的任何障礙。The main task in this category removing any obstacles to regular Teams client updates. 依預設,小組會定期自動更新 (除非您關閉該設定,否則我們不建議) 。By default, Teams automatically updates regularly (unless you turn off that setting, which we don't recommend).

您也應該監視裝置,並在您發現與裝置相關的問題時提供更新。You should also monitor devices and provide updates whenever you identify problems related to a device.

使用 CQD 管理通話品質Use CQD to manage call quality

在您設定 CQD之後,您就可以開始使用它來管理貴組織的通話與會議品質。Once you've set up CQD, you're ready to start using it to manage call and meeting quality for your organization.

團隊效能的大部分問題都屬於下列類別:Most problems with Teams performance fall into the following categories:

  • 防火牆或 proxy 配置不完整Incomplete firewall or proxy configuration
  • 低 wi-fi 覆蓋範圍Poor Wi-Fi coverage
  • 頻寬不足Insufficient bandwidth
  • 點對點VPN
  • 用戶端版本與驅動程式不一致或過時Inconsistent or outdated client versions and drivers
  • 未優化或內建音訊裝置Unoptimized or built-in audio devices
  • 有問題的子網或網路裝置Problematic subnets or network devices

如果您要花點時間來評估這些區域並修正任何不足的問題,您就可以減少為所有使用者維持高品質的團隊體驗所需的工作量。If you take the time before you roll out Teams to assess these areas and remediate any deficiencies, you'll reduce the amount of effort needed to maintain a high-quality Teams experience for all your users. 若要協助評估您的網路以準備您的團隊推出,請參閱小組的顧問準備您的小組網路For help assessing your network in preparation for your Teams rollout, read Advisor for Teams and Prepare your network for Teams.

使用 CQD 的預期Expectations using CQD

使用通話品質儀表板 (CQD) ,深入瞭解使用團隊和商務用 Skype 服務所進行的通話品質。Use the Call Quality Dashboard (CQD) to gain insight into the quality of calls made by using Teams and Skype for Business services. CQD 的設計目的是協助小組和商務用 Skype 系統管理員和網路工程師優化網路,並密切瞭解品質、可靠性和使用者體驗。CQD is designed to help Teams and Skype for Business admins and network engineers optimize the network and keep a close eye on quality, reliability, and the user experience. CQD 會在整個組織中查看匯總遙測,其中的整體模式可能會變得很明顯;這可讓您做出明智的評定及規劃修正。CQD looks at aggregate telemetry for an entire organization, where overall patterns can become apparent; this lets you make informed assessments and plan remediation. CQD 提供可讓您深入瞭解整體品質、可靠性和使用者體驗的度量報告。CQD provides reports of metrics that provide insight into overall quality, reliability, and user experience.

CQD 雖然對分析趨勢和子網很有用,但並不一定會針對特定案例提供特定原因。CQD, although useful for analyzing trends and subnets, doesn't always provide a specific cause for a given scenario. 請務必瞭解這一點,並在使用 CQD 時設定正確的預期:It's important to understand this and set the correct expectation when using CQD:

  • CQD 不會針對每個案例提供根源CQD won't provide the root cause for every scenario
  • CQD 不包含電話系統或音訊會議串流CQD won't contain Phone System or Audio Conferencing streams
  • CQD 將會根據趨勢來撥打進一步調查的區域CQD will call out areas for further investigation based on trends

CQD 報表概覽CQD reports overview

使用畫面頂端的下拉式功能表來開啟報表。Use the drop-down menu at the top of the screen to open a report. 如需每個報表中提供的資料清單,請參閱CQD 報表中的可用資料For a list of the data provided in each report, read Data available in CQD reports.

2020年1月的新功能:下載 POWER BI 查詢範本以進行 CQDNew in January 2020: Download Power BI query templates for CQD. 可自訂的 Power BI 範本,您可以用來分析及報告您的 CQD 資料。Customizable Power BI templates you can use to analyze and report your CQD data.

團隊與商務用 SkypeTeams vs. Skype for Business

CQD 可以同時報告團隊和商務用 Skype。CQD can report on both Teams and Skype for Business. 不過,有時候您可能會想要開發報表來查看團隊遙測與商務用 Skype 分開的情況。However, there might be times when you want to develop a report to look at Teams telemetry separate from Skype for Business.

摘要報告Summary reports

若要修改 [摘要報告] 頁面,只查看 [團隊] 或 [商務用 Skype],請從畫面頂端選取 [產品篩選] 下拉式功能表,然後選取您想要的產品。To modify the summary reports page to look at only Teams or Skype for Business, select the Product Filter drop-down menu from the top of the screen, and then select the product you want.

顯示 [篩選] 選項之下拉式功能表的螢幕擷取畫面

詳細報告Detailed reports

若要篩選所有詳細的報表,請在瀏覽器列中,將下列專案附加到 URL 的結尾:To filter all detailed reports, in the browser bar, append the following to the end of the URL:

/filter/[AllStreams].[Is Teams]|[FALSE]

範例Example:

https://cqd.teams.microsoft.com/cqd/#/1234567/2018-5/filter/[AllStreams].[Is Teams]|[FALSE]

如需 URL 篩選的詳細資訊,請參閱本節稍後的篩選報表For more information about URL filters, read Filtering reports later in this section.

若要篩選個別的詳細報表,請將篩選新增 Is Teams 至報表,並將其設定為 True 或 False。To filter an individual detailed report, add the filter Is Teams to the report and set it to True or False.

[新增篩選] 頁面的螢幕擷取畫面

受管理的與非管理的網路Managed versus unmanaged networks

根據預設,CQD 中的所有端點都會分類為外部。By default, all endpoints in CQD are classified as external. 一旦推出檔案,我們就可以開始查看受管理的端點資料。As soon as a building file is introduced, we can begin to look at managed endpoint data. 如先前所述,CQD 中的網路定義為:As previously discussed, networks in CQD are defined as:

  • 受管理的網路(通常稱為內部或內部)會受到組織的影響及控制。A managed network, often referred to as internal or inside, can be influenced and controlled by the organization. 這包括內部局域網、遠端 WAN 和 VPN。This includes the internal LAN, the remote WAN, and VPN.
  • 未受管理的網路(通常稱為外部或外部)不會受到組織的影響或控制。An unmanaged network, often referred to as external or outside, can't be influenced or controlled by the organization. 未受管理的網路範例是賓館或機場網路。An example of an unmanaged network is a hotel or airport network.

維度、量值與篩選Dimensions, measures, and filters

標準格式的 CQD 查詢包含下列三個參數:A well-formed CQD query contains all three of the following parameters:

  • 維度: 我要如何旋轉資料。Dimension: How I want to pivot on the data.

  • 測度: 我想要報告的內容。Measure: What I want to report on.

  • 篩選: 我要如何減少查詢所傳回的資料集。Filter: How I want to reduce the dataset the query returns.

另一個要看的是,_維度_是分組函數,一個_量值_是我感興趣的資料,而 [篩選] 是我想要將結果縮小到與我的查詢相關的結果。Another way to look at this is that a dimension is the grouping function, a measure is the data I'm interested in, and a filter is how I want to narrow down the results to those that are relevant to my query.

標準格式的查詢範例會顯示「資料流程」 [Measure] (由子網 [Dimension])來建立 6 [Filter]An example of a well-formed query is Show me Poor Streams [Measure] by Subnet [Dimension] for Building 6 [Filter]. 如需詳細資訊,請參閱CQD 中可用的維度與量值For more information, see Dimensions and measures available in CQD.

第一個與第二個First vs. second

CQD 中的許多維度與量值會分類為第一或第二個。Many of the dimensions and measures in CQD are classified as first or second. CQD 不使用 [來電者/被叫方] 欄位 ,因為呼叫者與被_叫方之間有中間的步驟,所以它們已_重新命名。CQD doesn't use caller/callee fields—these have been renamed first and second because there are intervening steps between the caller and callee. 下列邏輯決定所涉及的端點標示為「第一」:The following logic determines which endpoint involved is labeled as first:

  • 首先, (會議服務器、中繼伺服器等的伺服器端點,以及在資料流程或呼叫中包含伺服器時) 。First will always be a server endpoint (Conference Server, Mediation Server, and so on) if a server is involved in the stream or call.

  • 第二個將一直是用戶端端點,除非資料流程位於兩個伺服器端點之間。Second will always be a client endpoint unless the stream is between two server endpoints.

  • 如果兩個端點都是相同類型,則首先根據使用者代理程式類別的內部順序來選擇。If both endpoints are the same type, the choice of which is first is based on internal ordering of the user agent category. 這可確保順序一致。This ensures the ordering is consistent.

如需判斷第一個或第二個端點相同的詳細資訊,請參閱CQD 中可用的維度與量值For more information about determining the first or second endpoint when they're both the same, see Dimensions and measures available in CQD.

資料流程與撥號Stream vs. call

您必須瞭解通話與資料流程間的差異,才能正確選擇您要在 CQD 中看到的維度或量值。You need to understand the difference between a call and a stream to properly choose which dimensions or measures you'll be looking at in CQD. 雖然 CQD 的主要焦點是位於資料流程上,但也提供以呼叫為基礎的度量單位。Although CQD's primary focus is on streams, call-based measurements are also available.

  • 串流:_資料流程_存在於兩個端點之間。Stream: A stream exists between only two endpoints. 每個方向只有一個資料流程,且需要兩個數據流才能進行通訊。There is only one stream for each direction, and two streams are required for communication. 資料流程對於調查建築物、網路或子網很有用。Streams are useful for investigating buildings, networks, or subnets. 在某些情況下,通話和資料流程是在量化指標的名稱中使用 (例如,呼叫設定資料流程或呼叫中斷串流) 。In some cases, both call and stream are used in the measurement's name (for example, Call Setup Stream or Call Dropped Stream). 這些專案仍會分類為串流。These are still classified as streams.

  • 通話:_通話_是來自所有參與者的所有資料流程的群組。Call: A call is a grouping of all streams from all participants. 通話至少包含兩個數據流。A call consists of—at minimum—two streams. 單一通話至少會有兩個端點,每個端點最少為一個串流。A single call will have at least two endpoints, each with a minimum of one stream.

如需有關維度或量值是參照至通話或資料流程的其他指導方針,請參閱CQD 中可用的維度與量值For additional guidance on whether the dimension or measure is referring to a call or a stream, see Dimensions and measures available in CQD

良好、較差及未分類通話Good, poor, and unclassified calls

通話會分類為良好、較差或未分類。A call is categorized either as good, poor, or unclassified. 讓我們花點時間深入討論每一個專案。Let's take a moment to talk about each one in more detail.

  • 良好或不佳:[良好或較差的通話] 包含一組完整的服務度量,由服務產生並接收完整的 QoE 報告。Good or poor: A good or poor call consists of a call that contains a complete set of service metrics, for which a full QoE report was generated and received by the service. 在本文先前所述,判斷資料流程是否良好或變差。Determining whether a stream is good or poor is described earlier in this article.

  • 分類: 未分類的資料流程不包含完整的一組服務度量單位。Unclassified: An unclassified stream doesn't contain a full set of service metrics. 這些可能是短通話(通常少於60秒),因為無法計算平均值,也不會產生 QoE 報告。These can be short calls—usually less than 60 seconds—where averages couldn't be computed and a QoE report wasn't generated. 未分類呼叫最常見的原因,就是幾乎沒有資料包利用率。The most common reason for calls to be unclassified is that there was little to no packet utilization. 例如,參與者在靜音和永不說話時加入會議。An example of this would be a participant who joins a meeting on mute and never speaks. 參與者正在接收,但無法傳送媒體。The participant is receiving, but not transmitting, media. 如果沒有傳送媒體,就不會有任何可供 CQD 用來分類端點的輸出媒體資料流程的指標。Without media being transmitted, there won't be any metrics available for CQD to use to classify the endpoint's outbound media stream.

若要深入瞭解,請參閱CQD 中的資料流程分類To learn more, read Stream classification in CQD.

常見子網Common subnets

常見子網是賓館、家用網路、熱點及類似區域所使用的專用子網。Common subnets are specific private subnets that are used by hotels, home networks, hotspots, and similar areas. 這些子網難以進行會審,因為其廣泛使用。These subnets are difficult to triage due to their widespread use. 如果您的組織使用其中一個常見的子網,我們建議您將該網路移至另一個子網。If your organization uses one of these common subnets, we recommend that you move that network to another subnet. 這將使 CQD 的報告變得更容易。This will make reporting easier in CQD. 請注意,[所有網路] 範本中的報告已設定為排除這些子網,以將其排除在品質較差的來源。When noted, reports in the All Networks template have been configured to exclude these subnets to eliminate them as a source of poor quality. 常見的子網定義如下:其影響會因組織而異。Common subnets are defined below; their impact will vary by organization.

  • 10.0.0.0/2410.0.0.0/24
  • 192.168.0.0/24192.168.0.0/24
  • 192.168.1.0/24192.168.1.0/24
  • 192.168.2.0/24192.168.2.0/24
  • 172.20.10.0/24172.20.10.0/24
  • 192.168.43.0/24192.168.43.0/24

調查使用共同子網的受管理網路時,您需要使用第二個反身本機 IP 維度來組成群組子網。When investigating a managed network that uses a common subnet, you'll need to use the Second Reflexive Local IP dimension to group subnets. 此維度包含端點的公用 IP 位址。This dimension contains the endpoint's public IP address.

可靠性調查Reliability investigations

改善品質的第一個步驟是評估整個組織的可靠性狀態。The first step to improving quality is to assess the state of reliability across the organization. 因為可靠性對於積極的使用者體驗至關重要,所以我們從測量可靠性的兩個元件開始:Because reliability is vital to a positive user experience, we start with the two components that measure reliability:

  1. 安裝失敗: 無法建立通話。Setup failures: The call couldn't be established.

  2. Drop 失敗: 通話已建立且意外終止。Drop failures: The call was established and unexpectedly terminated.

在本節中,我們將說明同時調查兩個區域的方法。Throughout this section, we'll cover methods to investigate both areas.

注意

本文並未涵蓋範本中包含的所有報表。Not all reports included in the templates are covered in this article. 不過,以下所述的調查方法仍適用。However, the methods of investigation explained below still apply. 如需詳細資訊,請參閱個別報表的描述。Please refer to the individual report description for more information.

設定失敗Setup failures

首先,請優先處理此區域中的修正設定失敗問題,因為這些失敗會對使用者體驗產生嚴重的負面影響。Prioritize remediating setup failures in this area first, because these failures have a significant negative impact on the user experience.

您可以評估組織的整體設定失敗百分比,然後根據組建或網路最高的百分比來排定調查區域的優先順序。Begin your investigation by assessing the percentage of overall setup failures for the organization, and then prioritize areas of investigation based on the highest percentage by building or network.

設定失敗趨勢分析Setup failure trend analysis

此報告顯示串流的總總量、資料流程設定失敗,以及資料流程設定失敗率。This report displays the total amount of streams, stream setup failures, and the stream setup failure rate. 指向任何一個資料行,以顯示其個別的值。Point to any one of the columns to display its individual values.

分析Analysis

您可以使用此報告來回答下列問題,並決定您的下一個動作課程:By using this report, you can answer the following questions and determine your next course of action:

  • 目前月份的電話設定失敗總百分比是什麼?What is the total call setup failure percentage for the current month?

  • [通話設定失敗] 的總百分比是低於或高於定義的目標度量嗎?Is the total call setup failure percentage below or above the defined target metric?

  • 失敗趨勢是否較差或比上個月更佳?Is the failure trend worse or better than the previous month?

  • 失敗趨勢是增加、穩定或遞減嗎?Is the failure trend increasing, steady, or decreasing?

不論這些問題的答案如何,請使用隨附子報表來進一步調查,以尋找任何可能需要修正的個別建築物或子網。Irrespective of your answers to these questions, take the time to investigate further by using the companion sub-reports to look for any individual buildings or subnets that might need remediation. 雖然整體失敗率可能低於目標度量,但一或多個建築物或網路的失敗率可能高於目標指標,且需要調查。Although the overall failure rate might be below the target metric, the failure rates for one or more buildings or networks might be above the target metric and need investigation.

設定失敗調查Setup failure investigations

這個摘要報告是用來探索及隔離任何可能需要修正的建築物或網路。This summary report is used to discover and isolate any buildings or networks that might need remediation.

注意

請務必將 [月年度] 報表篩選調整為 [本月]。Be sure to adjust the Month Year report filter to the current month. 選取 [編輯],然後調整 [] 報表篩選,以儲存新的預設月份。Select Edit, and adjust the Month Year report filter to save the new default month.

修正Remediation

將您的第一次修正工作重點放在具有最大大量故障的建築物或子網上。Focus your first remediation efforts on buildings or subnets that have the largest volume of failures. 這將會最大化對使用者體驗的影響,並有助於快速減少組織電話設定失敗的速度。This will maximize impact on the user experience and help to quickly reduce the rate of organizational call setup failures. 下表列出由 CQD 報告的設定失敗的兩個原因。The following table lists the two reasons for setup failures as reported by CQD.

通話設定失敗的原因Call Setup Failures reason 常見的原因Typical cause
遺失固件深層資料包檢查例外規則Missing FW Deep Packet Inspection Exemption Rule 表示由於深入的資料包檢查規則而使媒體路徑無法建立,所以沿著路徑的網路裝置無法進行建立。Indicates that network equipment along the path prevented the media path from being established due to deep packet inspection rules. 這可能是因為防火牆規則沒有正確設定。This is likely due to firewall rules not being correctly configured. 在這種情況下,TCP 握手成功,但 SSL 握手沒有。In this scenario, the TCP handshake succeeded but the SSL handshake didn't.
遺失的 FW IP 封鎖例外規則Missing FW IP Block Exception Rule 表示路徑中的網路裝置無法建立媒體路徑給 Microsoft 365 或 Office 365 網路。Indicates that network equipment along the path prevented the media path from being established to the Microsoft 365 or Office 365 network. 這可能是因為無法正確設定 proxy 或防火牆規則,以允許存取用於團隊和商務用 Skype 流量的 IP 位址和埠。This might be due to proxy or firewall rules not being correctly configured to allow access to IP addresses and ports used for Teams and Skype for Business traffic.

當您開始修正時,您可以將精力集中在特定的建築物或子網上。As you begin your remediation, you can focus your efforts on a particular building or subnet. 如上表所示,這些問題是由防火牆或 proxy 設定所導致。As the preceding table shows, these issues are due to firewall or proxy configurations. 請參閱下表中的選項,以取得修正動作。Review the options in the following table for remediation actions.

修正Remediation 指導方針Guidance
設定防火牆Configure firewalls 與您的網路小組合作,並對照Office 365 IP 位址清單驗證您的防火牆設定。Work with your network team and verify your firewalls configuration against the Office 365 IP address list.

確認媒體子網和埠都包含在防火牆規則中。Verify that the media subnets and ports are included in the firewall rules.

確認在防火牆中開啟必要的埠Verify that the necessary ports are opened in the firewall. UDP 應該有優先權,因為 TCP 被視為音訊、影片和影片畫面共用的容錯回復通訊協定,而其使用會影響通話品質。UDP should be given priority because TCP is considered a failback protocol for audio, video, and video-based screen sharing, and its use will affect the quality of the call. 舊版 RDP 應用程式共用只使用 TCP。Legacy RDP application sharing uses TCP only.

Drop 失敗Drop failures

與 setup 失敗代碼不同的是,CQD 沒有 drop 失敗程式碼來指出為什麼會發生 drop 失敗,這會讓您難以隔離特定的根本原因。Unlike setup failure codes, CQD has no drop failure code to indicate why drop failures occur, which makes it difficult to isolate a specific root cause. 若要更完善的會審放下失敗,請使用推理的方法。To better triage drop failures, use an inferred approach. 透過修正媒體的任何感興趣區域、修補用戶端和驅動程式,以及推動小組和商務用 Skype 的認證裝置使用量,您可能會想要拒絕丟單失敗。By remediating any areas of interest for media, patching clients and drivers, and driving usage of certified devices for Teams and Skype for Business, you can expect drop failures to decline.

丟單失敗趨勢分析Drop failure trend analysis

此報告顯示音訊流量總量、總丟單失敗次數及擊落失敗率。This report displays the total amount of audio streams, total drop failures, and the drop failure rate. 指向任何一個資料行,以顯示其值。Point to any one of the columns to display its values.

分析Analysis

透過使用這種類型的報表,您可以回答下列問題:By using this type of report, you can answer the following questions:

  • 目前的擊落失敗率為何?What is the current drop failure rate?
  • Drop 失敗率是否低於定義的目標度量?Is the drop failure rate below the defined target metric?
  • 失敗趨勢是否較差或比上個月更佳?Is the failure trend worse or better than the previous month?
  • 失敗趨勢是增加、穩定或遞減嗎?Is the failure trend increasing, steady, or decreasing?

無論上述問題的答案如何,請花時間調查子報表,以尋找任何可能需要修正的建築物或網路。Irrespective of the answers to the questions above, take the time to investigate using the sub-reports to look for any buildings or networks that might need remediation. 雖然整體 drop 失敗率可能低於目標度量,但一或多個建築物或網路的擊落失敗率可能高於目標指標,且需要調查。Although the overall drop failure rate might be below the target metric, the drop failure rate for one or more buildings or networks might be above the target metric and need investigation.

擊落失敗調查Drop failure investigations

在此報告的失敗指示此通話被意外丟棄,並產生消極的使用者體驗。Failures reported here indicate that the call was dropped unexpectedly and resulted in a negative user experience. 與趨勢報告不同,這些報告提供其他深入瞭解需要進一步調查之子網的深入見解。Unlike the trending reports, these reports provide additional insights into specific subnets that need further investigation.

修正Remediation

使用隨附的表格報告,您可以隔離網路中超過您所定義之目標度量的問題區域。Using the included table reports, you can isolate problem areas in the network where the drop rate is above the target metric you've defined. 將您的第一次修正工作重點放在具有最高總串流數的建築物或子網上,以產生最大的影響。Focus your first remediation efforts on buildings or subnets that have the highest total stream count, to make the biggest impact.

呼叫下降的常見原因:Common causes of call drops:

  • 預配的網路或網際網路出口Under-provisioned network or internet egress
  • 受限制的網路上沒有設定 QoSNo QoS configured on constrained networks
  • 舊版用戶端版本Older client versions
  • 使用者行為User behavior

在您探索問題區域之後,您可以使用每個使用者的呼叫分析,進一步查看該組建中的特定問題的使用者。After you discover your problem areas, you can use per-user call analytics to further review users in that building for specific issues. [通話分析] 包含其他 EUII 資料,對於進一步產生 drop 失敗的可能原因也很有用。Call analytics contains additional EUII data and can be useful for further isolating potential reasons for the drop failures.

無論下一個步驟為何,建議您的技術人員在特定建築物或子網中發現的問題都是一種很好的做法。Regardless of your next step, it's a good practice to notify your helpdesk that an issue has been discovered with specific buildings or subnets. 這可讓技術支援人員快速回應來電,並更有效率地會審使用者。This lets the helpdesk quickly respond to incoming calls and triage users more efficiently. 然後,您可以將已標記的使用者報告回到工程小組,進一步進行調查。Flagged users can then be reported back to the engineering team for further investigation.

下表列出一些常見的管理與修正失敗的方法。The following table lists some common methods to manage and remediate drop failures.

修正Remediation 指導方針Guidance
Network/網際網路Network/internet 擁塞:與您的網路小組合作,以監視特定建築物/子網上的頻寬,以確認是否有使用過度的問題。Congestion: Work with your network team to monitor bandwidth at specific buildings/subnets to confirm that there are issues with overutilization. 如果您確認有網路擁塞,請考慮增加建立或應用程式 QoS 的頻寬。If you do confirm that there is network congestion, consider increasing bandwidth to that building or applying QoS. 使用隨附品質較差的資料流程摘要報告來查看問題子網,以取得抖動、延遲和資料包遺失的問題,因為這些通常會位於刪除的資料流程前面。Use the included Quality Poor Stream summary reports to review the problem subnets for issues with jitter, latency, and packet loss, because these will often precede a dropped stream.

QoS:如果增加頻寬是不切實際或成本不高,請考慮實施 QoS。QoS: If increasing bandwidth is impractical or cost-prohibitive, consider implementing QoS. 這個工具非常適合用來管理擁塞的通訊,並能保證受管理的網路上的媒體資料包在非媒體流量上方的優先順序。This tool is very effective at managing congested traffic and can guarantee that media packets on the managed network are prioritized above non-media traffic. 或者,如果沒有明確的證據證明存在頻寬問題,請考慮下列解決方案:Alternatively, if there's no clear evidence that bandwidth is the culprit, consider these solutions:
執行網路準備情況評估:網路評量提供預期頻寬使用量的詳細資料,以及如何處理頻寬和網路變更,以及團隊與商務用 Skype 的建議網路使用做法。Perform a network readiness assessment: A network assessment provides details about expected bandwidth usage, how to cope with bandwidth and network changes, and recommended networking practices for Teams and Skype for Business. 使用上一個資料表做為您的來源,您有一份代表最佳候選評估的建築物或子網清單。Using the preceding table as your source, you have a list of buildings or subnets that are excellent candidates for an assessment.
**用戶端 (僅限商務用 Skype Online) **Clients (Skype for Business Online only) 某些舊版商務用 Skype 用戶端已已知、有記錄的媒體可靠性問題。Some older Skype for Business clients have known, documented issues with media reliability. 查看來自多個受影響使用者的呼叫分析報告,或在 CQD 中建立自訂用戶端版本表格報告Review the Call Analytics reports from multiple affected users, or create a custom Client Version table report in CQD filtered to specific buildings or subnets with Total Call Dropped Failure % measure. 這項資訊將協助您瞭解該特定建築物與特定用戶端版本中的呼叫中斷之間是否存在關聯性。This information will help you understand whether a relationship exists between call drops in that specific building and a specific version of the client.
裝置Devices 如果裝置是通話品質問題中的問題,請考慮更新違犯的裝置。If devices are the culprit in call-quality problems, consider updating offending devices. 若要深入瞭解,請參閱手機供團隊進一步瞭解。Read Phones for Teams to learn more.
使用者行為User behavior 如果您認為網路、裝置或用戶端都不是問題,請考慮開發使用者採用戰略,教育使用者如何最好地加入和結束會議。If you determine that neither network, devices, or clients are the issue, consider developing a user adoption strategy to educate users how to best join and exit meetings. 更聰明的團隊和商務用 Skype 使用者將能為會議中的所有參與者提供較佳的使用者體驗。A smarter Teams and Skype for Business user will produce a better user experience for all participants in the meeting. 例如,將電腦放在睡眠 (的使用者,只要關閉蓋子) 而不離開會議,就會將其分類為意外的呼叫下沉。For example, a user who puts their laptop to sleep (by closing the lid) without exiting the meeting will be classified as an unexpected call drop.

品質調查Quality investigations

在組織中,評估音訊品質狀態的下一個步驟是調查不良的串流速率 (PSR.EXE) 、TCP 及 proxy 使用方式。The next step to assess the state of audio quality across the organization is to investigate Poor Stream Rate (PSR), TCP, and proxy usage. 請務必記住,CQD 資料並不會提供特定的根本原因,而是提供可能的問題區域,以與適當的小組開始合作,以取得修正活動。It's important to remember that CQD data doesn't provide you a specific root cause, but instead provides you with likely problem areas to begin a collaborative conversation with the appropriate teams for remediation activities.

注意

本文並未涵蓋範本中包含的所有報表。不過,以下所述的調查方法仍適用于這些報表。Not all reports included in the templates are covered in this article; however, the methods of investigation explained below will still apply for those reports. 如需詳細資訊,請參閱個別報表的描述。Refer to the individual report description for more information.

品質Quality

PSR.EXE 百分比可用來指出組織是否為指定焦點區域的會議定義指標目標。The PSR percentages are used to indicate whether the organization is meeting defined metric targets for a given focus area. 請務必注意,即使高層百分比位於定義的目標中,個別的子網或建築物可能不符合已定義的目標,因此需要進一步調查。It's important to note that even if the high-level percentages are within the defined target, individual subnets or buildings might not meet the defined targets and, therefore, need further investigation. 例如,如果整個音訊 PSR.EXE 百分比是4月的2% (符合樣本目標),個別的建築物和子網可能仍會有較差的體驗,這取決於這2% 的整體分佈情況。For example, if the overall audio PSR percentage is 2 percent in April, which meets the sample target, individual buildings and subnets might still be having poor experiences, depending on the overall distribution of that 2 percent.

若要評估不良資料流程的百分比,請使用品質報告。To assess the percentage of poor streams, use the quality reports. 提供各種品質報告來審查整個、會議、二方、PSTN 通話、VPN 和會議室的規格。Various quality reports are provided to review metrics for overall, conferencing, two-party, PSTN calling, VPN, and meeting rooms. 提供每月、每週及每日報告以協助此處理程式。Monthly, weekly, and daily reports are provided to assist in this process. 每週和每日報告都受限於受管理的網路範本,以提高其效能並減少雜色。Weekly and daily reports are limited to the Managed Networks template to increase their effectiveness and reduce noise.

品質趨勢分析Quality trend analysis

[趨勢報告] 會隨著時間顯示品質資訊,並用於協助識別並瞭解每個興趣領域內的品質趨勢。Trending reports display quality information over time and are used to help identify and understand quality trends within each area of interest. 如上所述,範本中有一些報告樹,可用於調查品質;會議、二方、PSTN 通話、VPN 和會議室。As noted above, there are report trees included in the templates for investigating quality; conferencing, two-party, PSTN calling, VPN, and meeting rooms. 針對分析品質而言,調查程式是一樣的。For the purposes of analyzing quality, the investigative process is the same. 不過,我們建議您先開始使用會議,因為會議品質的任何改善也會對所有其他區域產生積極的影響。However, we recommend that you start with conferencing first, because any improvements in conference quality will also positively affect all other areas.

注意

調查兩方、PSTN 通話和會議室與調查會議類似。Investigating two-party, PSTN calling, and meeting rooms are similar to investigating conferencing. 焦點是隔離具有最差品質的建築物或子網,並找出品質不佳的原因。The focus is to isolate buildings or subnets that have the worst quality and identify the reason for the poor quality.

重要

VPN 式報告是使用第二個 VPN 維度來篩選。VPN-based reports are filtered by using the Second VPN dimension. 這個維度要求 VPN 網路介面卡正確地註冊為遠端存取配接器。This dimension requires that the VPN network adapter be properly registered as a Remote Access Adapter. VPN 廠商無法可靠地使用這個標誌,而且您的里程會根據貴組織部署的 VPN 供應商而有所不同。VPN vendors don't reliably use this flag, and your mileage will vary depending on the VPN vendor deployed at your organization. 如有需要,請使用建築物或網路名稱來修改VPN報告。Modify the VPN reports if needed by using the building or network name.

研究Investigation

您可以使用這些報表,回答下列問題:By using these reports, you can answer the following questions:

  • 目前的月份總 PSR.EXE 是什麼?What is the total PSR for the current month?
  • PSR.EXE 是否在定義的目標度量以下?Is the PSR below the defined target metric?
  • PSR.EXE 比上個月更糟或變得更好嗎?Is PSR worse or better than the previous month?
  • PSR.EXE 趨勢是增加、穩定或遞減嗎?Is the PSR trend increasing, steady, or decreasing?

無論上述問題的答案如何,您都可以使用子報表來尋找任何可能需要調查的建築物或子網,以取得調查的時間。Irrespective of the answers to the questions above, take the time to investigate by using the sub-reports to look for any buildings or subnets that might need investigation. 雖然整體 PSR.EXE 可能低於目標度量,但一或多個建築物或網路的 PSR.EXE,通常是指標及需求修正。Although the overall PSR might be below the target metric, often the PSR for one or more buildings or networks is above the metric and needs remediation.

品質調查Quality investigations

[品質摘要] 報告可讓您深入瞭解如何將串流分類為較差,並有助於隔離受管理網路中的問題區域。The quality summary reports give you deeper insight into what contributed to the streams' being classified as poor and helps to isolate problem areas in the managed network.

雖然所使用的尺寸可能會稍有不同,但每個報告都會包含總數據流、PSR.EXE 和品質不佳等的量值。Although the dimensions used might differ slightly between report, each report will include measures for total streams, total poor streams, PSR, and poor quality due to. 已針對每一個感興趣的領域建立報告:會議、二方、PSTN 通話、VPN 和會議室。Reports have been created for each area of interest: conferencing, two-party, PSTN calling, VPN, and meeting rooms. 受管理的網路範本包含其他報告,可利用透過組建檔案上傳的位置資訊。The Managed Network template includes additional reports to take advantage of the location information uploaded via the building file.

注意

常見的子網難以進行會審,因為其廣泛使用。Common subnets are difficult to triage due to their widespread use. 顯示用戶端公用 IP (第二筆回身本機 IP) 的報表,該報告已新增至 [所有網路] 範本,以協助使用常見網路的修正辦公室。A separate report that displays the client's public IP (Second Reflexive Local IP) has been added to the All Networks template to assist with remediating offices that use common networks.

螢幕擷取畫面顯示不佳的音訊資料流程摘要

修正Remediation

將修正工作集中在具有最大大量資料流程的建築物或子網上,因為這可讓您獲得最大的影響,並有助於快速改善使用者體驗。Focus your remediation efforts on buildings or subnets that have the largest volume of streams, because this will maximize impact and help to improve the user experience quickly. 使用抖動、資料包遺失及往返時間 (RTT) 測量,以瞭解品質不佳 (可能會有一個以上的問題) :Use the jitter, packet loss, and round-trip time (RTT) measurements to understand what's contributing to the poor quality (it's possible for there to be more than one problem):

  • 抖動:媒體資料包的使用速度可能不同,從而導致喇叭音效機器人。Jitter: Media packets are arriving at different speeds, which causes a speaker to sound robotic.
  • 資料包遺失:媒體資料包遭到刪除,這會造成遺失文字或音節的效果。Packet loss: Media packets are being dropped, which creates the effect of missing words or syllables.
  • RTT:媒體資料包需要花很長的時間才能取得目的地,這會建立 walkie talkie 的效果。RTT: Media packets are taking a long time to get to their destination, which creates a walkie-talkie effect.

若要協助您調查品質問題,請使用 [每使用者通話分析]。To assist your investigation into quality issues, use per-user call analytics. 使用通話分析,您可以查看特定會議或使用者的通話報告。With Call Analytics, you can look at a specific conference or user's call report. 此報告將包含 EUII/PII 資料,且在您尋找失敗的原因時很有用。This report will contain EUII/PII data and is useful when you're looking for the cause of a failure. 在您知道哪個組建受到影響之後,請直接追蹤該組建中的使用者。After you know which building is affected, it should be straightforward to track down users in that building.

別忘了讓您的技術支援人員知道這些網路出現品質問題,所以他們可以快速進行會審並回應來電。Don't forget to let your helpdesk know that these networks are experiencing quality issues, so they can quickly triage and respond to incoming calls.

修正Remediation 指導方針Guidance
聯網Networks 擁塞:過度使用或未預配的網路可能會導致媒體質量發生問題。Congestion: An overused or under-provisioned network can cause issues with media quality. 與網路小組合作,判斷來自使用者的網路連線至網際網路出口點是否有足夠的頻寬支援媒體。Work with the network team to determine whether the network connections from the user to the internet egress point has enough bandwidth to support media.

執行網路準備情況評估:網路評量提供預期頻寬使用量的詳細資料,以及如何處理頻寬和網路變更,以及團隊與商務用 Skype 的建議網路使用做法。Perform a network readiness assessment: A network assessment provides details about expected bandwidth usage, how to cope with bandwidth and network changes, and recommended networking practices for Teams and Skype for Business. 使用上一個資料表做為您的來源,您有一份代表最佳候選評估的建築物或子網清單。Using the preceding table as your source, you have a list of buildings or subnets that are excellent candidates for an assessment.
服務品質 (QoS)Quality of Service (QoS) QoS 是一種行之有效的工具,可協助您在擁擠的網路上劃分資料包優先順序,以確保它們的目的地和時間都保持不變。QoS is a proven tool to help prioritize packets on a congested network to ensure they arrive at their destination intact and on time. 考慮在整個組織中實現 QoS,以最大限度地提高頻寬限制的使用者體驗品質。Consider implementing QoS across your organization to maximize the quality of the user experience where bandwidth is constrained. QoS 將協助解決與大量資料包遺失相關的問題,以及減少抖動與往返時間等問題。QoS will help solve issues typically associated with high levels of packet loss, and—to a lesser degree—jitter and round-trip times.
Wi-fiWi-Fi Wi-fi 可能會對通話品質產生很大的影響。Wi-Fi can have a significant impact on call quality. Wi-fi 部署通常不會考慮 VoIP 服務的網路需求,而且通常是品質較差的來源。Wi-Fi deployments don't typically take into consideration the network requirements for VoIP services and are often a source of poor quality. 如需優化 Wi-fi 基礎結構的詳細資訊,請參閱這篇有關 wi-fi 規劃的文章For more information about optimizing your Wi-Fi infrastructure, see this article about Wi-Fi planning.

無線驅動程式:確認無線驅動程式是最新的。Wireless driver: Ensure that wireless drivers are up to date. 這將有助於降低與過時的驅動程式相關的任何較差的使用者經驗。This will help mitigate any poor user experience related to an outdated driver. 許多組織在其修補程式週期中不會包含無線驅動程式,而且這些驅動程式在幾年後可能會有修補程式。Many organizations don't include wireless drivers in their patch cycles, and these drivers can go unpatched for years. 許多無線問題都是透過確保無線驅動程式是最新的方式來解決。Many wireless issues are solved by ensuring the wireless drivers are up to date.

WMM:無線多媒體延伸 (WMM) ,也稱為 wi-fi 多媒體,提供無線網路的基本 QoS 功能。WMM: Wireless Multimedia Extensions (WMM), also known as Wi-Fi Multimedia, provides basic QoS features to wireless networks. 現代無線網路必須支援許多裝置。Modern wireless networks must support many devices. 這些裝置會爭用頻寬,而且可能會造成 VoIP 服務的品質問題,其中的速度與延遲是至關重要的。These devices compete for bandwidth and can lead to quality issues for VoIP services, where speed and latency are vital. 請諮詢您的無線轉銷商以取得詳細資訊,並考慮在無線網路上實施 WMM,以排定商務用 Skype 與團隊媒體的優先順序。Consult your wireless vendor for specifics and consider implementing WMM on your wireless network to prioritize Skype for Business and Teams media.

存取點密度:存取點可能太遠,或不在理想的位置。Access point density: Access points might be too far apart or not in an ideal location. 若要將潛在干擾降至最低,請在會議室中放置額外的存取點,並在不受牆壁或其他物件(也就是弱類型的位置)中放入較弱的位置。To minimize potential interference, place extra access points in conference rooms and in locations that aren't obstructed by walls or other objects where the Wi-Fi signal is weak.

2.4 ghz 與 5 ghz: 5 ghz 可提供較低的背景干擾與較高的速度,以及在使用 Wi-fi 部署 VoIP 時應優先的優先順序。2.4 GHz versus 5 GHz: 5 GHz provides less background interference and higher speeds, and should be prioritized when deploying VoIP over Wi-Fi. 不過,5 GHz 與 2.4 GHz 不一樣,也不會輕易滲透牆。However, 5 GHz isn't as strong as 2.4 GHz and doesn't penetrate walls as easily. 請檢查您的組建版面配置,判斷您可以信賴哪個頻率來取得最佳連接。Review your building layout to determine which frequency you can rely on for the best connection.
網路裝置Network device 較大型的組織可能會有成百上千個裝置分佈在網路上。Larger organizations might have hundreds of devices spread out across the network. 與您的網路小組共同作業,以確保使用者的網路裝置和網際網路都能維持在最新狀態。Work with your network team to ensure that the network devices from the user to the internet are maintained and up to date.
點對點VPN VPN 裝置並未傳統設計來處理即時媒體工作負載。VPN appliances aren't traditionally designed to handle real-time media workloads. 某些 VPN 設定會禁止使用 UDP (,這是媒體) 的首選通訊協定,且只依賴 TCP。Some VPN configurations prohibit the use of UDP (which is the preferred protocol for media) and rely on TCP only. 考慮實現 VPN 分割隧道解決方案,以協助將 VPN 減少為品質較差的來源。Consider implementing a VPN split-tunnel solution to help reduce VPN as a source of poor quality.
Clients
僅限 (商務用 Skype Online) (Skype for Business Online only)
確保定期更新所有用戶端。Ensure all clients are being regularly updated.
裝置Devices 如果裝置是通話品質問題中的問題,請考慮更新違犯的裝置。If devices are the culprit in call-quality problems, consider updating offending devices. 若要深入瞭解,請參閱手機供團隊進一步瞭解。Read Phones for Teams to learn more.
驅動程式Drivers 修補網路 (乙太網和 Wi-fi) 、音訊、影片和 USB 驅動程式都應該是整個修補程式管理原則的一部分。Patching network (Ethernet and Wi-Fi), audio, video, and USB drivers should be part of your overall patch management strategy. 更新驅動程式可解決許多品質問題。Many quality issues are solved by updating drivers.
Wi-fi 上的會議室Meeting rooms on Wi-Fi 我們強烈建議您使用至少 1 Gbps 乙太網連線,將會議室裝置連線至網路。We highly recommend that meeting room devices be connected to the network by using at least a 1-Gbps Ethernet connection. 會議室裝置通常包含多個音訊與影片流量,以及會議內容(例如螢幕共用),並具有比其他團隊或商務用 Skype 端點更高的網路需求。Meeting room devices typically include multiple audio and video streams, along with meeting content such as screen sharing, and have higher network requirements than other Teams or Skype for Business endpoints. 依定義,會議室只會在安裝期間提供福利的固定裝置。Meeting rooms are, by definition, stationary devices where Wi-Fi affords a benefit only during installation.

會議室需要進行額外的注意與注意,以確保使用這些裝置的體驗達到或超過預期。Meeting rooms need to be treated with extra care and attention to ensure that the experience using these devices is meeting or exceeding expectations. 會議室的品質問題通常會快速上報,因為它們通常是由資深的人員使用。Quality issues with meeting rooms are usually going to be escalated quickly, because they're often used by senior-level staff.

隨著便利性) 以外的所有專案 (,Wi-fi 效能通常小於有線連線。With all things being equal (apart from convenience), Wi-Fi performance is often less than a wired connection. 隨著「攜帶您自己的裝置」原則以及膝上型電腦的急劇增加,您通常會使用 Wi-fi 存取點。With the rise of "bring your own device" policies and the proliferation of laptops, Wi-Fi access points are often over-utilized. 即時媒體可能不會在 Wi-fi 網路上劃分優先順序,這可能會在高峰使用時間導致品質問題。Real-time media might not be prioritized on Wi-Fi networks, which can lead to quality issues during peak use times. 這種繁重的使用方式可能會與會議中有十二人的會議相符,每個人都有自己的膝上型電腦和智慧型手機,而且都與會議室裝置連線到相同的 Wi-fi 存取點。This heavy usage can coincide with a meeting where there might be a dozen people in attendance, each with their own laptop and smartphone, all connected to the same Wi-Fi access point as the meeting room device.

Wi-fi 只能看作是針對行動安裝的暫時解決方案,或在已正確設定 Wi-fi 以支援商務級即時媒體的情況下使用。Wi-Fi should only be considered as a temporary solution, for a mobile installation, or when Wi-Fi has been properly provisioned to support business-class, real-time–based media.

TCP-OUTTCP

傳輸控制通訊協定 (TCP) 被視為 [回切傳輸],而不是您想要用於即時媒體的主要傳輸。Transmission Control Protocol (TCP) is considered a failback transport and not the primary transport you want for real-time media. 因為 TCP 的全狀態性質,所以它是回切傳輸的原因。The reason it's a failback transport is due to the stateful nature of TCP. 例如,如果通話是在潛在的網路上進行,而媒體資料包則是在延遲後的數秒前(這是不再有用的資料包),這會使頻寬更糟,這可能會導致錯誤的情況。For example, if a call is made on a latent network and media packets are delayed, then packets from a few seconds ago—which are no longer useful—compete for bandwidth to get to the receiver, which can make a bad situation worse. 這會讓音訊 healer 縫合及伸展音訊,從而產生可聽見的專案,通常是以抖動的形式出現。This makes the audio healer stitch and stretch audio, resulting in audible artifacts, often in the form of jitter.

此區段中的報表不會對良好與不良的資料流程產生任何差異。The reports in this section don't make a distinction between good and poor streams. 考慮到 UDP 是可取的,報告會尋找使用 TCP 進行音訊、影片及影片的螢幕共用 (VBSS) 。Given that UDP is preferred, the reports look for the use of TCP for audio, video, and video-based screen sharing (VBSS). 提供的串流速率較差是為了協助比較 UDP 品質與 TCP 品質,讓您能專注于最大限度的效果。Poor stream rates are provided to help compare UDP quality versus TCP quality so that you can focus your efforts where the impact is the greatest. TCP 使用量主要是由不完整的防火牆規則所造成。TCP usage is primarily caused by incomplete firewall rules. 如需小組和商務用 Skype Online 防火牆規則的詳細資訊,請參閱Microsoft 365 和 Office 365 url 與 IP 位址範圍For more information about firewall rules for Teams and Skype for Business Online, see Microsoft 365 and Office 365 URLs and IP address ranges.

注意

[音訊]、[影片] 和 [VBSS],將所有偏好的 UDP 做為主要傳輸。Audio, video, and VBSS all prefer UDP as their primary transport. 舊版 RDP 應用程式共用工作負載只使用 TCP。The legacy RDP Application Sharing workload only uses TCP.

TCP 使用量TCP usage

TCP 報告表示過去七個月內的整體 TCP 使用量。TCP reports indicates the overall TCP usage over the last seven months. 本節中的所有進一步報告將重點向下縮小特定建築物,以及 TCP 最常使用的子網。All further reports in this section will focus on narrowing down specific buildings and subnets where TCP is most commonly used. 每個會議和兩方的資料流程都有不同的報表。Separate reports are available for both conferencing and two-party streams.

顯示使用 TCP 之音訊資料流程百分比的圖表

研究Investigation

您可以使用此報告回答下列問題:By using this report, you can answer the following questions:

  • 目前月份的 TCP 資料流程總容量為何?What is the total volume of TCP streams for the current month?
  • 它是否比前個月更糟或變得更好?Is it worse or better than the previous month?
  • TCP 使用量趨勢是增加、穩定或遞減嗎?Is the TCP usage trend increasing, steady, or decreasing?
  • TCP PSR.EXE 與我的整體 PSR.EXE 是否相同?Is the TCP PSR the same as my overall PSR?

如果您發現 TCP 使用量趨勢增加或高於正常的每月使用時間,請使用子報表來尋找任何可能需要修正的建築物或網路,以進行調查。If you notice that the TCP usage trend is increasing or above normal monthly usage, take the time to investigate by using the sub-reports to look for any buildings or networks that might need remediation. 理想的情況是,您想要在受管理的網路上盡可能少進行 TCP 式音訊會話。Ideally, you want as few TCP-based audio sessions as possible on the managed network.

TCP 與 UDPTCP vs. UDP

此報告會識別最新月份的 TCP 和 UDP 使用量報告的 VBSS,以進行音訊、影片及影片的螢幕共用 () 。This report identifies the volume of TCP versus UDP usage reporting on the latest month for audio, video, and video-based screen sharing (VBSS).

顯示使用 TCP 與 UDP 的資料流程數量的報告

分析Analysis

雖然您想要盡可能地降低 TCP 使用量,但您可能會在其他健康的部署中看到一些 TCP 使用量。Although you want TCP usage to be as low as possible, you might see a bit of TCP usage in an otherwise healthy deployment. TCP 本身不會對不佳的呼叫造成影響,因此會提供串流速度,以協助找出 TCP 使用量是否是品質不佳的參與者。TCP by itself won't contribute to a poor call, so stream rates are provided to help identify whether TCP usage is a contributor to poor quality.

TCP 調查TCP investigations

在提供的 CQD 範本中,您可以使用 [Managed 網路] 或 [所有網路] 範本來建立和子網報告,流覽至 TCP 資料流程。In the provided CQD templates, navigate to the TCP Streams by Building and Subnet reports by using either the Managed Networks or All Networks template. 出於調查 TCP 使用的目的,程式是一樣的,因此我們將重點放在會議上的討論。For the purpose of investigating TCP usage, the process is the same, so we'll focus the discussion here on conferencing.

修正Remediation

這個報告會識別對 TCP 使用量而言所造成的特定建築物與子網。This report identifies specific buildings and subnets that are contributing to the volume of TCP usage. 此外還包含額外的報告,以識別通話中所使用的 Microsoft 中繼 IP,以協助隔離遺失的防火牆規則。An additional report is also included to identify the Microsoft Relay IP that was used in the call to help isolate missing firewall rules. 將您的修正工作重點放在那些具有最高 TCP 資料流程的建築物上,以獲得最佳效果。Focus your remediation efforts on those buildings that have the highest volume of TCP streams to maximize impact.

TCP 使用的最常見原因是防火牆或 proxy 中缺少例外規則。The most common cause of TCP usage is missing exception rules in firewalls or proxies. 我們將在下一節中討論 proxy,所以現在將焦點放在防火牆上。We'll be talking about proxies in the next section, so for now focus your efforts on the firewalls. 使用所提供的建築物或子網,您可以判斷需要更新哪些防火牆。By using the building or subnet provided, you can determine which firewall needs to be updated.

修正Remediation 指導方針Guidance
設定防火牆Configure firewall 確認已從您的防火牆中排除Microsoft 365 或 Office 365 IP 埠和位址Verify that Microsoft 365 or Office 365 IP ports and addresses are excluded from your firewall. 針對媒體相關的 TCP 問題,請將您的初始工作重點放在下列各項:For media-related TCP issues, focus your initial efforts on the following:
  • 確認用戶端媒體子網 13.107.64.0/18 和 52.112.0.0/14 都在您的防火牆規則中。Verify that the client media subnets 13.107.64.0/18 and 52.112.0.0/14 are in your firewall rules.
  • UDP 埠3478–3481是必要的媒體埠,必須開啟,否則用戶端會傳回 TCP 埠443的故障。UDP ports 3478–3481 are the required media ports and must be opened, otherwise the client will fail back to TCP port 443.
是否Verify 使用Microsoft Network 評量工具,檢查與特定 Microsoft 365 或 OFFICE 365 IP 位址的連線問題,以及受影響的建築物或子網上的埠。Use the Microsoft Network Assessment Tool to check for issues with connectivity to specific Microsoft 365 or Office 365 IP addresses and ports from the affected building or subnet.

HTTP proxyHTTP proxy

出於許多原因,HTTP proxy 不是建立媒體會話的首選路徑。HTTP proxies aren't the preferred path for establishing media sessions, for a multitude of reasons. 許多包含可防止服務連線完成並帶來中斷的深資料包檢查功能。Many contain deep packet inspection features that can prevent connections to the service from being completed and introduce disruptions. 此外,幾乎所有的 proxy 都會強制 TCP,而不是允許使用 UDP,這是針對最佳音訊品質所建議的。Additionally, almost all proxies force TCP as opposed to allowing UDP, which is recommended for optimal audio quality.

我們總是建議您將用戶端設定為直接連線至團隊和商務用 Skype 服務。We always recommend that you configure the client to directly connect to Teams and Skype for Business services. 這對於媒體通信量而言尤為重要。This is especially important for media-based traffic.

重要

我們建議您上傳有效的組建檔案,讓您可以在分析 proxy 使用量時,區分外部音訊資料流程。We recommend that you upload a valid building file so you can distinguish inside from outside audio streams when analyzing proxy usage.

HTTP proxy 使用量HTTP proxy usage

範本這個區段中的 HTTP proxy 串流報告,與 TCP 報告非常類似。The HTTP proxy stream report in this section of the template is much like the TCP reports. 它不會查看通話是否較差或良好,但通話是否是經由 HTTP 連線。It doesn't look at whether calls are poor or good, but whether the call is connected over HTTP.

使用 HTTP 之音訊資料流程報告的螢幕擷取畫面

分析Analysis

您想要查看盡可能少的 HTTP 媒體資料流程。You want to see as few HTTP media streams as possible. 如果您有資料流程遍歷您的 proxy,請諮詢您的網路小組,以確保適當的排除措施正確無誤,讓用戶端直接路由至小組或商務用 Skype Online 媒體子網。If you have streams traversing your proxy, consult your networking team to ensure that the proper exclusions are in place so that clients are directly routing to Teams or Skype for Business Online media subnets.

如果您的組織只有一個網際網路 proxy,請確認正確的Microsoft 365 或 Office 365 url 與 IP 位址範圍排除If you have only one internet proxy in your organization, verify the proper Microsoft 365 or Office 365 URLs and IP address range exclusions. 如果您的組織中設定了多個網際網路 proxy,請使用 HTTP 子報表來隔離受影響的建築物或子網。If more than one internet proxy is configured in your organization, use the HTTP sub-report to isolate which building or subnet is affected.

對於無法繞過 proxy 的組織而言,請務必將商務用 Skype 用戶端設定為在 proxy 之後正確登入,如商務用 Skype 中所述,請使用 proxy 伺服器登入,而不是嘗試直接連線。For organizations that can't bypass the proxy, ensure that the Skype for Business client is configured to sign in properly when it's located behind a proxy, as outlined in the article Skype for Business should use proxy server to sign in instead of trying direct connection.

HTTP proxy 調查HTTP proxy investigations

此報告會識別出對 HTTP 使用量有影響的特定建築物與子網。This report identifies specific buildings and subnets that are contributing to HTTP usage.

修正Remediation

我們建議您永遠都不要針對商務用 Skype 和小組(尤其是媒體流量)略過這些代理。We recommend that you always bypass proxies for Skype for Business and Teams, especially media traffic. Proxy 不會讓商務用 Skype 更加安全,因為其流量已經過加密。Proxies don't make Skype for Business more secure, because its traffic is already encrypted. 效能相關問題可透過延遲與資料包遺失來引進環境。Performance-related problems can be introduced to the environment through latency and packet loss. 這類問題將會在即時資料流至關重要的情況下,使用音訊、影片和螢幕共用來產生負面體驗。Issues such as these will result in a negative experience with audio, video and screen sharing, where real-time streams are essential.

HTTP 使用的最常見原因是 proxy 中缺少例外規則。The most common cause of HTTP usage is missing exception rules in proxies. 使用所提供的建築物或子網,您可以快速判斷需要為媒體旁路設定哪些 proxy。By using the building or subnet provided, you can quickly determine which proxy needs to be configured for media bypass.

確認所需的Microsoft 365 或 Office 365 fqdn是在您的 proxy 中列入白名單。Verify that the required Microsoft 365 or Office 365 FQDNs are whitelisted in your proxy.

端點調查Endpoint investigations

本節重點針對用戶端版本的報告工作,以及使用已認證的裝置。This section is focused on the tasks for reporting on client versions and the use of certified devices. 您可以在用戶端版本、用戶端類型、捕獲裝置和驅動程式 (麥克風) 、視頻捕獲裝置以及 Wi-fi 供應商和驅動程式版本中使用報告。Reports are available to outline usage for client versions, client type, capture devices and drivers (microphone), video capture devices, and Wi-Fi vendor and driver versions.

注意

本文並未涵蓋範本中包含的所有報表。不過,以下所述的調查方法仍適用。Not all reports included in the templates are covered in this article; however, the methods of investigation explained below still apply. 如需詳細資訊,請參閱個別報表的描述。Refer to the individual report description for more information.

用戶端版本Client versions

這些報告主要是識別使用中的商務用 Skype 用戶端版本,以及其在環境中的相對量。These reports focus on identifying Skype for Business client versions in use and their relative volume in the environment.

重要

目前,團隊用戶端會透過 Azure 內容傳遞網路自動發佈並更新,並將由服務保持最新狀態。Currently, Teams clients are distributed and updated automatically through the Azure Content Delivery Network and will be kept up to date by the service. 因此,您不需要 (監視團隊用戶端版本,除非您關閉自動更新,否則我們不建議) 。As a result, you don't need to monitor Teams client versions (unless you turn off the auto updating, which we don't recommend).

除非您排除聯盟參與者資料,否則這些報告將包含來自聯盟端點的用戶端遙測。Unless you exclude federated participant data, these reports will include client telemetry from federated endpoints. 若要排除同盟端點,您必須在您組織的租使用者識別碼中,新增第二個租使用者 id 的查詢篩選器。To exclude federated endpoints, you must add a query filter for Second Tenant ID set to your organization's tenant ID. 或者,您也可以使用URL 篩選來排除同盟參與者遙測。Alternatively, you can use a URL filter to exclude federated participant telemetry.

修正Remediation

驅動高品質的使用者體驗的重要部分是,確保受管理的用戶端執行的是最新版本的商務用 Skype,除了可確保支援的音訊、影片、網路及 USB 驅動程式都是最新版本。A critical part of driving high-quality user experiences is ensuring that managed clients are running up-to-date versions of Skype for Business, in addition to ensuring the supporting audio, video, network, and USB drivers are up to date. 這提供數個優點,其中包括:This provides several benefits, among them:

  • 更容易管理幾個版本,與許多版本相比。It's easier to manage a few versions versus many versions.
  • 它提供經驗的一致性等級。It provides a level of consistency of experience.
  • 它可讓您更輕鬆地排查通話品質和可用性問題。It makes it easier to troubleshoot problems with call quality and usability.
  • Microsoft 會持續進行整個產品的一般改善及優化。Microsoft continually makes general improvements and optimizations across the product. 確保使用者收到這些更新,會降低遇到已解決問題的風險。Ensuring that users receive these updates reduces their risk of running into a problem that has already been solved.

將您的部署限制在超過六個月之前的用戶端版本,將可減少所需支援的版本數,改善使用者的整體體驗並改善易管理性。Limiting your deployment to client versions that are less than six months old will improve the overall user experience and improve manageability by reducing the number of versions that need to be supported.

如果您使用的是 Office 隨選即用,您會自動在六個月內的視窗中。If you're using only Office Click-to-Run, you'll automatically be within the six-month window. 不需要進一步的動作。No further action is required.

如果您有混合式隨選即用與安裝程式套件 (的 MSI) ,您可以使用報告來確認 MSI 用戶端定期更新。If you have a mix of Click-to-Run and installer packages (MSI), you can use the report to verify that the MSI clients are being updated regularly. 如果您發現用戶端落後,請與負責管理 Office 更新的小組合作,並確定他們要定期核准和部署用戶端修補程式。If you notice clients are falling behind, work with the team responsible for managing Office updates and ensure that they're approving and deploying client patches regularly.

您也必須考慮並確保網路、影片、USB 和音訊驅動程式也有修補。It's also important to consider and ensure that the network, video, USB, and audio drivers are being patched as well. 您可以輕鬆地忽略這些驅動程式,而不要將它們包含在您的修補程式管理原則中。It can be easy to overlook these drivers and not include them in your patch management strategy.

您可以透過下列連結找到商務用 Skype 的版本號碼:Version numbers for Skype for Business can be found via the links below:

裝置Devices

若要使用麥克風裝置報表,我們需要瞭解 (MOS) 的平均觀念分數概念。To make use of the microphone device report, we need to understand the concept of the mean opinion score (MOS). MOS 是用來估量所察覺之音訊品質的黃金標準測量。MOS is the gold-standard measurement to gauge the perceived audio quality. 它是從0到5的整數評分來表示。It's represented as an integer rating from 0 to 5.

語音品質的所有測量單位都是人員如何感覺語音品質。The basis of all measures of voice quality is how a person perceives the quality of speech. 因為它受到人類的認知影響,所以本身就是主觀的。Because it's affected by human perception, it's inherently subjective. 主觀測試有數種不同的方法。There are several different methodologies for subjective testing. 大多數語音品質測量都是以絕對分類分級為基礎, (ACR) 縮放。Most voice quality measures are based on an absolute categorization rating (ACR) scale.

在 ACR 主觀測試中,以統計為單位,大量的使用者在 () (不正確的) 中,以較高的速度來評定其體驗品質。In an ACR subjective test, a statistically significant number of people rate their quality of experience on a scale of 1 (bad) to 5 (excellent). 分數的平均值是 MOS。The average of the scores is the MOS. 產生的 MOS 取決於向群組所公開的經驗範圍,以及評級的經驗類型。The resulting MOS depends on the range of experiences that were exposed to the group and to the type of experience being rated.

因為對即時通訊系統進行語音品質的主觀測試是不切實際的,所以 Microsoft 團隊和商務用 Skype 會使用高級演算法來產生 MOS 值,以客觀預測主觀測試的結果。Because it's impractical to conduct subjective tests of voice quality for a live communication system, Microsoft Teams and Skype for Business generate MOS values by using advanced algorithms to objectively predict the results of a subjective test.

可用的一組 MOS 及相關的度量單位可提供透過音訊裝置傳送給使用者的體驗品質。The available set of MOS and associated metrics provide a view into the quality of the experience being delivered to the users by an audio device.

您可以為擁有針對小組和商務用 Skype 認證的裝置提供使用者,以減少因裝置本身而遇到負面體驗的可能性 (如此一來,例如,內建的膝上型電腦喇叭和麥克風) 。By supplying users with devices certified for Teams and Skype for Business, you reduce the likelihood of encountering negative experiences due to the device itself (which is more likely, for example, with built-in laptop speakers and microphones). 如需詳細資訊,請參閱認證計畫合作夥伴解決方案目錄中的相關文章。For more information, see these articles on the certification program and the partner solutions catalog.

裝置報告是用來依音量和 MOS 分數來評估裝置使用量 (只) 音訊],而且可以在 [用戶端 & 裝置] 下的隨附範本中找到。The device reports are used to assess device usage by volume and MOS score (audio only), and can be found in the accompanying templates under Clients & Devices.

重要

除非您排除聯盟參與者資料,否則這些報告將包含來自聯盟端點的用戶端遙測。Unless you exclude federated participant data, these reports will include client telemetry from federated endpoints. 若要排除同盟端點,您必須在您組織的租使用者識別碼中,新增第二個租使用者 id的查詢篩選器。To exclude federated endpoints, you must add a query filter for Second Tenant ID set to your organization's tenant ID. 或者,您也可以使用URL 篩選來排除同盟參與者遙測。ALternatively, you can use a URL filter to exclude federated participant telemetry.

注意

您可能會注意到,當您查看此報告時,您會看到多次報告相同的裝置。You might notice when viewing this report that you see the same device reported multiple times. 這是由於將裝置報告給 CQD 的方式所導致。This is due to the way the device is reported being reported to CQD. 硬體與作業系統區域設定的差異會導致報告裝置資料的方式差異。Differences in hardware and OS locale cause differences in how device data is reported.

修正Remediation

通常,您需要探索並階段找出未認證的裝置,並將它們取代為認證的裝置。Typically, you'll need to discover and phase out non-certified devices and replace them with certified devices. 查看裝置報告時的一些考慮事項包括:Some considerations when reviewing the device reports include:

  • 適用于團隊和商務用 Skype 的裝置是否已獲認證?Are the devices in use certified for Teams and Skype for Business?
  • 您可以使用每個使用者的呼叫分析來識別特定裝置的使用者。You can identify users of a specific device by using per-user call analytics. 請檢查以確定他們擁有最新的裝置驅動程式,且其裝置未透過 USB 集線器或塢站連接。Check to make sure they have the latest device drivers and that their device isn't connected through a USB hub or docking station.
  • 各種不同的驅動程式版本在使用中有多少不同?How many different versions of various drivers are in use? 他們是定期進行修補嗎?Are they being patched regularly? 確保定期修補音訊、影片和 Wi-fi 驅動程式,以協助將這些問題排除在品質問題的來源,並讓使用者體驗更具預見性和一致性。Ensuring that audio, video, and Wi-Fi drivers are being patched regularly will help eliminate these as a source of quality issues and make the user experience more predictable and consistent.
音訊Audio

下一個工作是判斷認證音訊裝置的整體使用量。The next task is to determine the overall usage of certified audio devices. 我們建議您至少80% 的所有音訊資料流程都使用經過認證的音訊裝置。We recommend that at least 80 percent of all audio streams use a certified audio device. 最佳做法是將麥克風裝置報告匯出至 Excel,以計算認證或核准裝置的使用方式。This is best accomplished by exporting the microphone devices report to Excel to calculate the usage of certified or approved devices. 組織通常會保留所有核准裝置的清單,因此篩選及排序資料應該相當簡單。Organizations typically keep a list of all approved devices, so filtering and sorting the data should be straightforward.

影片Video

影片驅動程式也很重要,就是繼續更新。Video drivers are important to keep updated as well. 確保經常修正的視訊卡,將無法排除視頻驅動程式,因為這是視頻串流品質較差的來源。Ensuring that video cards are being regularly patched will help exclude video drivers as a source of poor quality for video streams. 使用經過驗證的影片裝置將有助於確保使用者體驗順暢且高品質。Using certified video devices will help ensure a smooth and high-quality user experience. 支援 H-p 原生編碼的視頻裝置是可取的,以減少在視訊會議期間的 CPU 使用量。Video devices that support H.264 native encoding are preferred, to reduce CPU usage during video conferencing.

Wi-fiWi-Fi

Wi-fi 驅動程式也必須在一般節奏上進行修補,而且應該包含在您的修補程式管理原則中。Wi-Fi drivers also need to be patched on a regular cadence as well and should be included in your patch management strategy. 您可以透過維護最新的 Wi-fi 驅動程式來修正許多品質問題。Many quality issues can be corrected by maintaining up-to-date Wi-Fi drivers. 如需優化 Wi-fi 基礎結構的詳細資訊,請參閱這篇有關 wi-fi 規劃的文章For more information about optimizing your Wi-Fi infrastructure, see this article about Wi-Fi planning.

針對團隊使用顧問Use Advisor for Teams

準備用於 Teams 的網路Prepare your network for Teams

Office 365 網路連接原則Office 365 Network Connectivity Principles

團隊分析和報告Teams analytics and reporting

在 Teams 中管理裝置Manage your devices in Teams

改善及監視團隊的通話品質Improve and monitor call quality for Teams

什麼是 CQD?What is CQD?

設定通話品質儀表板 (CQD) Set up Call Quality Dashboard (CQD)

上傳租使用者及組建資料Upload tenant and building data

CQD 資料和報表CQD data and reports

CQD 中可用的維度與量值Dimensions and measures available in CQD

CQD 中的資料流程分類Stream Classification in CQD

使用 Power BI 來分析 CQD 資料Use Power BI to analyze CQD data