在 Microsoft Teams 中使用 CQD 管理通話和會議品質
本文將透過使用 Microsoft Teams 通話品質儀錶板 (CQD) ，協助您開發監控及維護貴組織通話與會議質量的程式。 我們的指導方針強調音訊品質案例，因為您為改善音訊體驗所做的任何網路改良，都會轉換成視訊和共用中的改進。
本指引的關鍵為兩個 精選的 CQD 範本 -建議您先下載，再流覽本文中的指引。
本文假設您已經 設定 CQD。
要監視和維護的類別
在 Teams 中推出會議和語音功能後，您將需要持續監視和維護的計劃。 這樣做可確保Teams一律以最佳方式執行。 此計劃應包含下列重要領域。 您也應該建立品質計量的目標，以及疑難解答和隔離問題時的規劃。
| 類別 | 描述 |
|---|---|
| 通話品質 |
透過組織內的內部通話 (來細分計量，例如 VPN、WiFi、有線) 或外部通話 透過建置或網路來細分計量 VPN 通話 使用 TCP、UDP 或 Proxy 通話 |
| 通話可靠性 | 找出並補救任何網路或防火牆問題 深入瞭解通話設定和捨棄失敗的百分比 瞭解大多數的通話設定和捨棄失敗發生的位置 |
| 使用者問卷調查 |
使用 [我的通話評分] 數據來瞭解用戶的實際體驗 不良體驗在哪裡發生？ 將不佳的通話體驗與通話品質、可靠性和裝置相互關聯 |
| 裝置 | 瞭解哪些麥克風和喇叭最常使用，以及它們對通話質量的影響 支援的音訊、視訊、USB 和WiFi驅動程式是否定期修補？ |
| 用戶端 |
瞭解正在使用哪些客戶端類型和版本及其對通話品質和可靠性的影響 |
透過持續評估和補救本文所述的區域，您可以降低這些區域對使用者造成負面影響的可能性。 大部分的使用者問題可以分成下列類別：
- 不完整的防火牆或 Proxy 設定
- 不佳的 Wi-Fi 涵蓋範圍
- 帶寬不足
- Vpn
- 不一致或過時的用戶端版本和驅動程式
- 不優化或內建的音訊裝置
- 有問題的子網或網路裝置
在部署 Teams 或 商務用 Skype Online 之前，透過適當的規劃和設計，您可以減少維持高質量體驗所需的投入量。
本文著重於使用 [通話品質儀錶板] (CQD) Online 做為報告和調查每個區域的主要工具，並特別強調音訊以最大化採用和影響。 對網路所做的任何改善，以改善音訊體驗，也會直接翻譯成視訊和桌面共用的改良功能。
為了加快您的評定，系統會提供 兩個精選的 CQD 範本 ：一個用於管理所有網路，另一個則僅針對受管理 (內部) 網路進行篩選。 雖然 [所有網络] 範本報告已設定為顯示建築物和網路資訊，但您在收集和上傳建築物資訊時，仍然可以使用這些報告。 將建築物資訊上傳到 CQD 可讓服務透過新增自定義建築物、網路和位置資訊來強化報告，同時將內部與外部子網區隔。 如需詳細資訊，請參閱 建築物對應。
預定物件
本文旨在讓合作夥伴和客戶關係人使用共同作業潛在客戶、架構、顧問、變更管理/採用專家、支援/技術支援人員潛在客戶、網路潛在客戶、桌面潛在客戶和IT管理員等角色。
什麼是品質？
在此情況下，品質是服務計量和用戶體驗的組合。
服務計量
服務計量包含特定的用戶端計量。 在每次通話期間，用戶端會收集通話的遙測，並在每次通話結束時提交報告，以便日後在 CQD 或 個別使用者的通話分析中存取。 這些計量包括 (，但不限於) ：
- 不良 Stream (內送和外寄)
- 設定失敗率
- 捨棄失敗率
不佳的串流速率
不佳的串流率 (PSR) 代表組織整體品質不佳的串流百分比。 此衡量標準旨在強調貴組織可專心投入哪些區域，以針對降低此值及改善用戶體驗產生最強烈的影響，這也是為什麼當您查看 PSR 時， 受管理的網路 成為主要焦點的原因。 外部使用者也很重要，但調查在組織上有所不同。 考慮為外部使用者提供最佳做法，並調查與整個組織無關的外部通話。
CQD 中的實際度量會因工作負載而不同，但基於本文的考慮，我們主要著重於 音訊不佳百分比 度量。 PSR 由下表中所述的五個網路計量平均值組成。 若要將串流分類為不佳，只有一個計量需要超過定義的閾值。 CQD 提供「因為...不佳而不佳」以更深入了解導致串流被歸類為不佳的條件。 若要深入瞭解，請參閱在 CQD 中 Stream 分類。
備註
CQD 提供「因為...而不佳」以更深入了解導致串流被歸類為不佳的條件。
音訊品質不佳指派
| 公制平均值 | 描述 | 使用者體驗 |
|---|---|---|
| Jitter >30 ms | 這是連續封包之間延遲的平均變更。 Teams 和 商務用 Skype 可以透過緩衝來適應某些程度的抖動。 只有當抖動超過緩衝時，參與者才會注意到抖動的效果。 | 封包以不同的速度送達，會造成喇叭的聲音聽起來像機器人。 |
| 封包遺失率 >10% 或 0.1 | 這通常會定義為遺失封包的百分比。 封包遺失會直接影響音訊質量，因為小型的個別封包遺失幾乎不會影響連續連連損損，而造成音訊完全完全中斷。 | 封包掉落而未送達其預定目的地，會造成媒體間的空白，導致遺漏音節和文字，以及斷斷續續的視訊和共用。 |
| 往返時間 >500 ms | 這是從 A 點取得 IP 封包來指向 B 並返回指向 A 點所需的時間。此網路傳播延遲與兩點之間的實體距離和光速系結，並且在網路路徑中包含各種裝置所佔用的額外負荷。 | 封包到達目的地花費太多時間會造成無線對講機效果。 |
為什麼我們偏好使用串流而非通話？
Streams 會讓我們知道通話的哪個特定段子很差 - 外寄或來電。 當您查看不佳通話的通話分析數據時，請判斷通話不佳是否因為該來電者的串流 (輸出) 或來電者的串流 (輸入) 。 決定哪一個串流會影響通話品質，對會議來說更為重要。 如果您只查看通話數據，您會看到一個人參與的會議數目，但您不會看到哪些人是作用中的喇叭，他們最多會分享屏幕畫面。
通話數據提供您使用量計量，但不一定會導致通話品質不佳的根本原因。 藉由查看串流方向，您可以識別不在受管理網路上的通話、非員工 (例如廠商或不同網路) 人員的通話等因素。 在這些情況下，如果另一人的網路連線不佳，則整個通話會標示為不佳。 您無法對外部因素執行任何動作，因此此資料沒有説明。
Stream 方向也可以協助您識別有問題的裝置或用戶端。
例如，如果您的裝置預算有限，而且只想提供大量音訊用戶的裝置，請使用 VoIP) (音訊使用方式報告，並篩選輸出串流和會議。 尋找使用內建麥克風說話的高音量音訊使用者，這些音訊使用者可能與較差的通話品質 (相互關聯，而您可能會想要為這些人員提供音訊裝置) 。 為了提高明確性，您可以篩選封包使用量，這可讓您特別針對高音量音訊使用者。
另一個範例是使用螢幕畫面分享。 如果客戶使用舊的 Teams 用戶端，螢幕畫面分享效能可能會受到影響。 您可以為進行大量螢幕畫面分享的使用者排定用戶端升級的優先順序來解決此問題。
藉由識別哪一個串流方向導致通話品質不佳，您可以判斷您是否有 QoS 或頻寬相關問題。 如果您尚未完全實作 QoS，或者如果您只在用戶端標記封包，而非輸入串流，您可能會看到較差的通話品質。 透過查看串流方向，您可以更細分地檢視特定方向的封包遺失、延遲或抖動。
- 例如，假設使用者在使用有線連線 (抖動) 時抱怨有聲機音訊。 透過查看串流和方向，您可以判斷問題只會發生在輸入串流上，只針對一組特定的子網。 在您將這項資訊提供給您的網路小組之後，他們可以追蹤到設定錯誤的WAN加速器，而該加速器不會略過媒體流量。 網路小組重新設定WAN加速器后，抖動就會消失，且通話品質會改善。
設定失敗率
設定失敗率，又稱為 CQD 中的 [ 總通話設定失敗百分比 ] 度量，是通話開始時，在端點之間無法建立媒體路徑的串流數目。
這代表無法建立的任何媒體串流。 由於此問題對用戶體驗的影響嚴重性，目標是盡可能將此值降低為接近零。 在防火牆規則不完整的新部署中，高值對於此計量而言較常見，但定期 watch 仍很重要。
此計量的計算方式是計算無法設定的串流總數，除以提交成功通話詳細數據記錄的串流總數 (CDR) ：
- 設定失敗率 = 總通話設定失敗 Stream 計數 / 可用的 CDR 總計 Stream Count
捨棄失敗率
在 CQD 中，下拉式失敗率，又稱為「 總通話中斷百分比」 度量，就是媒體路徑未正常終止之成功建立串流的百分比。
這代表任何意外終止的媒體串流。 雖然此問題的影響並不像無法設定的串流那麼嚴重，但仍會對用戶體驗造成負面影響。 媒體突然和頻繁的中斷不僅會嚴重影響用戶體驗，還會導致使用者需要重新連線，導致生產力遺失 (提及挫折) 。
計量的計算方式是計算掉落的串流總數，除以成功設定的串流總數：
- 下拉失敗率 = 總通話率捨棄 Stream 計數 / 總通話設定成功 Stream 計數
定義目標計量
本節討論我們用來評估服務健康情況的一些核心服務計量。 藉由持續評估並推動將這些計量保持在其定義目標下方，您將可協助確保您的用戶體驗一致且可靠的通話品質。 首先，請使用下表中的建議目標。 視需要調整目標以達成您的業務目標。
| 網路類型 | 質量目標 | 可靠性目標 | ||
|---|---|---|---|---|
| 音訊不佳 Stream 速率 | 設定失敗率 | 捨棄失敗率 | ||
| * All | 內部 | 2.0% | 0.5% | 2.0% |
| 整體 | 3.0% | 1.0% | 3.0% | |
| 會議 | 內部 | 2.0% | 0.5% | 2.0% |
| 內部有線 | 1.0% | 0.5% | 1.0% | |
| Wi-Fi 5 GHz 內部 | 1.0% | 0.5% | 1.0% | |
| Wi-Fi 2.4 GHz 內部 | 2.0% | 0.5% | 2.0% | |
| 整體 | 2.0% | 0.5% | 3.0% | |
| P2p | 內部 | 2.0% | 0.5% | 2.0% |
| 有線/Wi-Fi 5 GHz 內部 | 1.0% | 0.5% | 1.0% | |
| 整體有線/Wi-Fi 5 GHz | 2.0% | 1.0% | 1.0% | |
| 整體 | 2.0% | 1.0% | 3.0% | |
使用者體驗
分析用戶體驗比科學更美觀，因為這裡收集的計量不一定代表網路或服務有問題，而是只是指出使用者已察覺到問題。 CQD 包含內建的問卷機制— [我的通話評分] (RMC) — 以協助評估整體用戶體驗。 從用戶的觀點來看，RMC 可讓您深入瞭解下列問題：
- 我知道如何使用解決方案嗎？
- 解決方案是否易於使用且直覺，而且是否支援我的日常通訊需求？
- 解決方案是否協助我完成工作？
- 我對於解決方案的整體感受為何？
- 無論我身在何處，我都可以隨時使用解決方案嗎？
- 我可以設定和維護通話嗎？
為我的通話評分
Teams 和 商務用 Skype 內建的 RMC (RMC) 評分我的通話。 它會在每10個通話中自動跳出一個，即10%。 這項簡短調查會要求使用者為通話評分，並提供通話品質不佳的一些內容。 一或兩個評分視為不佳，三到四是良好，五個則很棒。 雖然這有點落後的標記，但對於發現服務計量可能遺漏的問題而言，這是很實用的指標。
備註
人為因素：當通話品質良好時，使用者通常會忽略問卷調查，而且會在通話品質不佳時填寫問卷。 因此，即使服務計量良好，您的 RMC 報告仍可能偏態到不佳的狀況。
您可以使用 CQD 來報告 RMC 用戶回應，而範例報告會包含在 CQD 範本中。 不過，本文並未詳細說明這些內容。
用戶端和裝置整備
您需要穩固的用戶端和裝置策略，以協助確保用戶擁有一致且正面的用戶體驗。 幾個關鍵原則會推動每個整備策略。
用戶端整備
讓 Teams 用戶端保持在最新狀態，可確保您的使用者隨時獲得最佳體驗。 Microsoft 會經常向 Teams 客戶 端發行更新 (除非您關閉這項功能，否則更新會在背景中自行安裝，我們不建議) 。 請務必記得修補網路、視訊、USB 和音訊驅動程式，因為這些驅動程式通常會被忽略，而且可能會影響通話和會議品質。 考慮將網路、Wi-Fi、視訊、USB 和音訊驅動程式新增至您目前的修補程式管理程式。
裝置整備
除了裝置整備策略之外，沒有任何單一策略會影響用戶體驗。 例如，仰賴膝上型電腦喇叭和麥克風的使用者在通話和會議中會遇到許多背景噪音。 Teams 的設計可與幾乎任何裝置搭配使用，但如果您遇到裝置相關問題，請查看 Teams 版手機。
質量類別
操作一組品質管理做法，這可讓您獲得良好的通話和會議品質。 良好的品質管理計劃可解決下列類別：
網路：音訊品質著重於不佳的 Stream 比例 (PSR) 計量、TCP 使用量、有線和無線子網，以及識別 HTTP Proxy 和 VPN 的使用
端點： 音訊裝置和最新用戶端
服務管理： 此類別由兩個區段組成：
首先，Microsoft 有責任管理及維護 Teams 和 商務用 Skype Online 服務。
第二項是貴組織為了確保服務的可靠存取權所管理的工作，例如更新建築物資訊，以及在新增基礎結構至服務時維護新 Office 365 IP 位址的防火牆。
檢閱下列建議維持品質的工作清單。 您應該定期執行這些工作，例如每周執行一次。
服務管理工作
這些工作的範圍包括確保有足夠的頻寬可以送達服務而不使因特網鏈接飽和、驗證 QoS () 服務品質已位在所有受管理的網路區域，以及掌握防火牆上的 Office 365 IP 範圍。
網路工作
網路工作有兩種類別：可靠性和品質。 可靠性的重點在於測量使用者成功撥打電話並保持連線的能力。 質量著重於使用者用戶端在通話期間和通話結束後傳送給Teams和 商務用 Skype Online 的匯總遙測。
由於可靠性對用戶體驗有重大影響，建議您先評估並調查可靠性計量，再研究品質。
端點工作
拿掉 一般 Teams 用戶端更新的任何障礙，此類別的主要工作。 根據預設，除非您關閉該設定，否則Teams會定期 (更新，我們不建議) 。
每當您發現裝置相關問題時，您也應該監視裝置並提供更新。
使用 CQD 管理通話品質
設定 CQD 之後，您就可以開始使用它來管理組織的通話和會議品質。
Teams 效能問題大部分屬於下列類別：
- 不完整的防火牆或 Proxy 設定
- 不佳的 Wi-Fi 涵蓋範圍
- 帶寬不足
- Vpn
- 不一致或過時的用戶端版本和驅動程式
- 不優化或內建的音訊裝置
- 有問題的子網或網路裝置
如果您在推出 Teams 之前花一些時間評估這些區域並補救任何不足之處，您將會減少為所有使用者維持高品質 Teams 體驗所需的投入量。 如需協助評估您的網路以準備 Teams 推出，請參閱 Teams 建議 程式和 準備 Teams 的網路。
使用 CQD 的預期
使用 [通話品質儀錶板] (CQD) ，以深入瞭解使用 Teams 和 商務用 Skype 服務的通話品質。 CQD 的設計目的是要協助 Teams 和 商務用 Skype 系統管理員和網路工程師優化網路，並密切注意品質、可靠性和用戶體驗。 CQD 會查看整個組織的匯總遙測，其中整體模式可能會變得明顯;這可讓您進行明智的評定和計劃補救。 CQD 提供計量報告，提供整體品質、可靠性和用戶體驗的深入解析。
CQD 雖然對分析趨勢和子網很有用，但不一定能為特定案例提供特定原因。 請務必瞭解這一點，並在使用 CQD 時設定正確的期望：
- CQD 不會提供每個案例的根本原因
- CQD 會根據趨勢指出要進一步調查的區域
CQD 報告概觀
使用畫面頂端的下拉功能表開啟報表。 如需每個報告中提供的數據清單，請參閱 CQD 報告中可用的數據。
2020 年 1 月的新功能： 下載適用於 CQD 的 Power BI 查詢範本。 您可以使用可自訂的 Power BI 範本來分析及報告 CQD 資料。
Teams 與 商務用 Skype
CQD 可以同時報告 Teams 和 商務用 Skype。 不過，有時候您可能會想要建立報表，將Teams遙測與 商務用 Skype分開查看。
摘要報表
若要修改摘要報告頁面，只查看 Teams 或 商務用 Skype，請從畫面頂端選取 [產品篩選] 下拉功能表，然後選取您要的產品。
詳細報告
若要篩選所有詳細報告，請在瀏覽器列中，將下列報告附加到 URL 的結尾：
/filter/[AllStreams].[Is Teams]|[FALSE]
例子：
https://cqd.teams.microsoft.com/cqd/#/1234567/2018-5/filter/[AllStreams].[Is Teams]|[FALSE]
如需 URL 篩選的詳細資訊，請參閱本節稍後的 篩選報 表。
若要篩選個別的詳細報告，請將篩選 Is Teams 新增至報表，並將它設定為 True 或 False。
![[新增篩選] 頁面的螢幕快照。](media/qerguide-image-addteamsfilter.png)
受管理與未受管理的網路
根據預設，CQD 中的所有端點都會分類為外部端點。 一旦推出建築物檔案，我們就可以開始查看受管理的端點數據。 如先前討論的，CQD 中的網路定義為：
- 受管理的網路通常稱為內部或內部，可能會受到組織的影響及控制。 這包括內部 LAN、遠端 WAN 和 VPN。
- 未受管理的網路通常稱為外部或外部，不受組織影響或控制。 未受管理的網路範例是旅館或機場網路。
維度、量值和篩選
已形成的 CQD 查詢包含下列三個參數：
維 度： 如何對數據進行樞紐分析。
措施： 我想要回報的內容。
濾波器： 我要如何減少查詢傳回的數據集合。
另一個觀察方式是， 維度 是群組函數，一個 度量 就是我感興趣的數據，而 篩選 則是我要縮小結果範圍到與查詢相關的結果。
已形成查詢的範例是，第 6 號大樓 [篩選] 的 Subnet [Dimension] 顯示不佳的 Streams [Measure]。 如需詳細資訊，請參閱 CQD 中提供的維度和量值。
第一個與第二個
CQD 中許多維度和量值都分類為第一或第二。 CQD 不會使用來電者/來電者欄位，因為來電者和來電者之間有互動式步驟，因此已將這些字段重新命名為 第一 個和第 二 個。 下列邏輯會判斷所涉及的端點會標示為第一個：
第 一個永遠是伺服器端點， (會議伺服器、中接伺服器等) 如果伺服器是參與串流或通話。
除非 串流位於兩個伺服器端點之間，否則 Second 永遠都是用戶端端點。
如果兩個端點都屬於同一種類型，則第一個端點的選擇是根據使用者代理程式類別的內部排序。 這可確保訂單一致。
如需判斷第一個或第二個端點相同時的詳細資訊，請參閱 CQD 中可用的維度和量值。
Stream 與通話
您必須瞭解通話與串流之間的差異，才能在 CQD 中正確選擇要查看的維度或量值。 雖然 CQD 的主要焦點位於串流上，但也可以使用通話型測量。
Stream：串流只存在於兩個端點之間。 每個方向只有一個串流，通訊需要兩個串流。 對於調查建築物、網路或子網而言，串流很有用。 在某些情況下，通話和串流都會用於度量值的名稱 (例如通話設定 Stream 或通話中斷 Stream) 。 這些專案仍被歸類為串流。
叫：通話是所有參與者的所有串流群組。 通話至少包含兩個串流。 一個通話至少會有兩個端點，每個端點至少有一個串流。
如需維度或度量是否參照通話或串流的其他指導方針，請參閱 CQD 中可用的維度和量值
良好、不佳和未分類的通話
通話會分類為良好、不佳或未分類。 讓我們花點時間更詳細地討論每一個。
良好或不佳： 良好或不佳的通話包含一組完整的服務計量電話，服務會針對該服務產生和接收完整的 QoE 報告。 本文稍早所述的判斷是否為良好或不佳的串流。
未分類： 未分類的串流不包含一整組服務計量。 這些可以是簡短通話，通常不到 60 秒，其中無法計算平均值且未產生 QoE 報告。 取消分類通話最常見的原因是，封包使用率很少。 此範例是以靜音加入會議且永不說話的參與者。 參與者正在接收媒體，但不會傳送媒體。 若不傳輸媒體，CQD 將不會有任何指派可用來分類端點的輸出媒體串流。
若要深入瞭解，請閱讀 CQD 中的 Stream 分類。
一般子網
常見的子網是旅館、家庭網路、熱點和類似區域所使用的特定私人子網。 這些子網由於廣泛使用而難以分級。 如果您的組織使用這些常用子網的其中一個，建議您將該網路移到另一個子網。 這會讓 CQD 中的報表更容易。 註明后，[所有網络] 範本中的報表已設定為排除這些子網，以消除它們作為品質不佳的來源。 一般子網定義如下;其影響會因組織而異。
- 10.0.0.0/24
- 192.168.0.0/24
- 192.168.1.0/24
- 192.168.2.0/24
- 172.20.10.0/24
- 192.168.43.0/24
在調查使用一般子網的受管理網路時，您需要使用第二個反身本機 IP 維度來群組子網。 此維度包含端點的公用IP位址。
可靠性調查
改善品質的第一個步驟是評估整個組織的可靠性狀態。 由於可靠性對於正面的用戶體驗非常重要，我們首先從兩個測量可靠性的元件開始：
安裝程序失敗： 無法建立通話。
捨棄失敗： 通話已建立，且意外終止。
在本節中，我們將說明調查這兩個區域的方法。
備註
本文並未涵蓋範本中包含的所有報告。 不過，下列說明的調查方法仍適用。 如需詳細資訊，請參閱個別報告描述。
安裝程序失敗
請優先處理此區域中的修復安裝失敗，因為這些失敗會對用戶體驗造成嚴重的負面影響。
藉由評估組織整體設定失敗百分比來開始調查，然後根據建立或網路的最高百分比來排列調查區域的優先順序。
設定失敗趨勢分析
此報表會顯示串流總數量、串流設定失敗，以及串流設定失敗率。 指向任一欄以顯示其個別值。
分析
您可以使用這份報告回答下列問題，並決定下一個動作程式：
當月總通話設定失敗百分比為何？
總通話設定失敗百分比是否低於或高於定義的目標計量？
失敗趨勢是否比上個月差或更好？
失敗趨勢是遞增、穩定或減少嗎？
無論您對這些問題的回答為何，請利用隨附子報表來尋找任何可能需要修復的個別建築物或子網，藉此進一步調查。 雖然整體失敗率可能低於目標計量，但一或多個建築物或網路的失敗率可能高於目標計量，需要調查。
安裝程式失敗調查
此摘要報告是用來探索並隔離任何可能需要修復的建築物或網路。
備註
請務必將月份年度報表篩選調整為目前月份。 選取 [編輯]，然後調整 [月份年 ] 報表篩選以儲存新的預設月份。
修復
第一次修復工作的焦點在於發生失敗量最大的建築物或子網。 這將最大化對用戶體驗的影響，並協助快速降低組織通話設定失敗的速度。 下表列出設定失敗兩個原因，如 CQD 所報告。
| 通話設定失敗原因 | 一般原因 |
|---|---|
| 遺失 FW 深度封包檢查免稅規則 | 表示路徑上的網路設備因深度封包檢查規則而無法建立媒體路徑。 這可能是因為未正確設定防火牆規則。 在此案例中，TCP 交會成功，但 SSL 交會沒有成功。 |
| 遺失 FW IP 封鎖例外規則 | 表示路徑上的網路設備阻止媒體路徑建立至 Microsoft 365 或 Office 365 網路。 這可能是因為 Proxy 或防火牆規則未正確設定為允許存取 Teams 和 商務用 Skype 流量所使用的 IP 位址和埠。 |
當您開始修復時，您可以將精力集中在特定的建築物或子網上。 如上表所示，這些問題是防火牆或 Proxy 設定所造成。 檢閱下表中的選項以取得補救動作。
| 修復 | 指導方針 |
|---|---|
| 設定防火牆 | 與您的網路小組合作，並根據 Office 365 IP位址清單驗證您的防火牆設定。 確認防火牆規則中包含 媒體子網 和埠。 確認防火牆中已開啟 必要的埠 。 UDP 應優先處理，因為 TCP 被視為音訊、視訊及視訊螢幕共用的故障回溯通訊協定，其使用方式會影響通話品質。 舊版 RDP 應用程式共用僅使用 TCP。 |
捨棄失敗
與設定失敗碼不同，CQD 沒有下拉式失敗碼來指出發生捨棄失敗的原因，這會讓您難以隔離特定的根本原因。 若要更完善的分級舍位失敗，請使用推斷的方法。 透過補救媒體、修補用戶端和驅動程式的任何相關領域，以及 Teams 和 商務用 Skype 認證裝置的使用方式，您可以預期捨棄失敗。
捨棄失敗趨勢分析
此報表會顯示音訊串流的總數量、總捨位失敗，以及捨棄失敗率。 指向任一欄以顯示其值。
分析
使用這種類型的報告，您可以回答下列問題：
- 目前的捨棄失敗率為何？
- 下拉式失敗率是否低於定義的目標計量？
- 失敗趨勢是否比上個月差或更好？
- 失敗趨勢是遞增、穩定或減少嗎？
不管上述問題的答案為何，請花一些時間使用子報表調查，尋找任何可能需要修復的建築物或網路。 雖然整體的捨棄失敗率可能低於目標計量，但一或多座建築物或網路的下拉式失敗率可能高於目標計量，需要調查。
捨棄失敗調查
此處回報的失敗表示通話意外中斷，並導致負用戶體驗。 不同於熱門報告，這些報告提供需要進一步調查之特定子網的其他深入解析。
修復
您可以使用包含的數據表報告，隔離網路中下拉速率高於您所定義之目標計量的問題區域。 第一次修復工作的焦點在於擁有最高串流計數的建築物或子網，以產生最大的影響。
通話次數減少的常見原因：
- 布建不足的網路或因特網出口
- 在受限制的網路上未設定 QoS
- 舊版用戶端版本
- 用戶行為
探索問題區域之後，您可以使用 個別用戶通話分析 ，進一步檢閱該大樓中的使用者是否發生特定問題。 通話分析包含其他 EUII 數據，對於進一步隔離發生捨棄失敗的潛在原因很有用。
無論下一個步驟為何，建議您通知技術服務人員特定建築物或子網發現問題。 這可讓技術服務人員快速回應來電，並更有效率地分級使用者。 系統會接著將已標幟的用戶回報給工程小組，以進行進一步調查。
下表列出一些管理及補救下拉式清單失敗的常見方法。
| 修復 | 指導方針 |
|---|---|
| 網路/因特網 | 囯塞：請與您的網路小組合作，以監控特定建築物/子網的頻寬，以確認發生過度使用的問題。 如果您確實確認有網路囑塞，請考慮增加該建築物的頻寬，或套用 QoS。 使用包含的品質不佳 Stream 摘要報告來檢閱問題子網是否有抖動、延遲和封包遺失的問題，因為這些問題通常會在掉落的串流之前。 QoS：如果增加頻寬不切實際或成本禁止，請考慮實作 QoS。 此工具在管理擁擠的流量時非常有效，而且可以保證受管理網路上的媒體封包優先於非媒體流量。 或者，如果沒有清楚證明頻寬是造成問題的辨別，請考慮下列解決方案： 執行網路整備評估：網路評估提供有關預期頻寬使用量、如何運用頻寬和網路變更的詳細數據，以及適用於Teams和 商務用 Skype的建議網路做法。 您可以使用上一個數據表做為來源，列出最適合評量的建築物或子網。 |
| 用戶端僅 (商務用 Skype Online) | 有些舊版 商務用 Skype 用戶端有已知的媒體可靠性問題。 檢閱來自多個受影響使用者的通話分析報告，或在 CQD 中建立自定義用戶端版本表格報表，該報表已篩選至特定建築物或子網，並以 [通話中斷總數百分比] 度量。 此資訊可協助您了解通話掉落於該特定建築物與用戶端的特定版本之間是否存在關聯。 |
| 裝置 | 如果裝置是通話品質問題的相關問題，請考慮更新有問題的裝置。 若要深入瞭解，請閱讀 Teams的電話 。 |
| 用戶行為 | 如果您判斷問題不是網路、裝置或用戶端，請考慮開發用戶採用策略，以教育使用者如何最好地加入及結束會議。 更聰明的 Teams 和 商務用 Skype 使用者將為會議中的所有參與者提供更好的用戶體驗。 例如，透過蓋上螢幕) 而不結束會議，將膝上型電腦置於睡眠 (的使用者，會被歸類為非預期的通話下拉式清單。 |
質量調查
下一個評估整個組織音訊質量狀態的步驟是調查不佳的 Stream 速率 (PSR) 、TCP 和 Proxy 使用量。 請務必記住，CQD 數據不會提供您特定的根本原因，而是提供您可能的問題區域，以便與適當的小組進行共同作業，以進行補救活動。
備註
本文並未涵蓋範本中包含的所有報告;不過，以下說明的調查方法仍適用於這些報告。 如需詳細資訊，請參閱個別報告描述。
品質
PSR 百分比可用來指出組織是否符合指定焦點區域的已定義計量目標。 請務必注意，即使高層級百分比在已定義的目標內，個別子網或建築物可能不符合定義的目標，因此需要進一步調查。 例如，如果 4 月份的整體音訊 PSR 百分比為 2%，符合範例目標，則根據 2% 的整體分佈，個別建築物和子網的體驗可能仍然不佳。
若要評估不佳串流的百分比，請使用質量報告。 我們提供各種質量報告，以檢閱整體、會議、兩方、PSTN 通話、VPN 和會議室的計量。 提供每月、每周及每日報告以協助此程式。 每周和每日報告僅限於受管理的網路範本，以提高其有效性並降低噪音。
質量趨勢分析
趨勢報表會顯示一段時間的品質資訊，並用來協助識別及瞭解各感興趣區域中的質量趨勢。 如上所述，在範本中包含了調查質量的報告樹;會議、雙方會議、PSTN 通話、VPN 和會議室。 為了分析品質，調查程式是相同的。 不過，建議您先從會議開始，因為會議品質的任何改善也會對所有其他區域產生正面的影響。
備註
調查雙方會議、PSTN 通話和會議室類似於調查會議。 重點在於隔離品質最差的建築物或子網，並找出品質不佳的原因。
重要
VPN 型報表是使用第二個 VPN 維度進行篩選。 此維度需要將 VPN 網路適配器正確登錄為遠端訪問適配卡。 VPN 廠商不會可靠地使用此標幟，而且您的里程數會根據您組織部署的 VPN 廠商而有所不同。 視需要使用建築物或網路名稱修改 VPN 報告。
調查
您可以使用這些報告回答下列問題：
- 目前月份的總 PSR 是什麼？
- PSR 是否低於定義的目標計量？
- PSR 是否比上個月差或更好？
- PSR 趨勢是遞增、穩定或減少嗎？
不管上述問題的答案為何，請利用子報表來尋找可能需要調查的任何建築物或子網，花一些時間進行調查。 雖然整體 PSR 可能低於目標計量，但一或多座建築物或網路的 PSR 通常高於計量，需要修復。
質量調查
品質摘要報告可讓您更深入地瞭解造成串流被歸類為不佳的原因，並有助於隔離受管理網路中的問題區域。
雖然報表之間使用的維度可能會稍有不同，但每個報表都會包含總串流的量值、總不佳的串流、PSR 和品質不佳的量值。 已針對各個感興趣的領域建立報告：會議、兩方會議、PSTN 通話、VPN 和會議室。 受管理的網路範本包含其他報告，可利用透過建築物檔案上傳的位置資訊。
備註
常見的子網由於廣泛使用而難以分級。 另一份顯示用戶端公用IP (第二個反身本機IP) 的報告已新增至[所有網路] 範本，以協助修復使用通用網路的辦公室。
修復
請將您的修復工作集中於擁有最大串流量的建築物或子網，因為這樣會最大化影響並協助快速改善用戶體驗。 使用 RTT) 測量 (抖動、封包遺失和往返時間，以瞭解造成品質不佳的原因 (可能有多個問題) ：
- 抖動：媒體封包的速度不同，這會讓喇叭發出聲響響。
- 封包遺失：媒體封包被丟棄，這會造成遺失單字或音節的效果。
- RTT：媒體封包需要很長的時間才能到達目的地，這會產生無線對講機效果。
若要協助您調查質量問題，請使用 個別用戶通話分析。 您可以使用通話分析查看特定會議或使用者的通話報告。 此報告將包含 EUII/PII 數據，而且在您尋找失敗的原因時很有用。 在您知道受影響的建築物之後，在該大樓中追蹤用戶應該很簡單。
別忘了讓技術服務人員知道這些網路發生質量問題，因此他們可以快速分級和回應來電。
| 修復 | 指導方針 |
|---|---|
| 網路 | 囑塞：過度使用或布建不足的網路可能會導致媒體質量問題。 與網路小組合作，判斷從使用者到因特網出口點的網路連線是否有足夠的頻寬支持媒體。 執行網路整備評估：網路評估提供有關預期頻寬使用量、如何運用頻寬和網路變更的詳細數據，以及適用於Teams和 商務用 Skype的建議網路做法。 您可以使用上一個數據表做為來源，列出最適合評量的建築物或子網。 |
| 服務品質 (QoS) | QoS 是經證實的工具，可協助排列壅塞網路上封包的優先順序，以確保它們到達目的地時完整且及時。 考慮在整個組織中實作 QoS，以最大化受限頻寬之用戶體驗的品質。 QoS 可協助解決通常與高度封包遺失相關的問題，以及在較小的程度上，抖動和往返時間。 |
| Wi-Fi | Wi-Fi 可能會嚴重影響通話品質。 Wi-Fi 部署通常不會考慮 VoIP 服務的網路需求，而且通常是品質不佳的來源。 如需優化 Wi-Fi 基礎結構的詳細資訊，請參閱 本文 Wi-Fi 規劃。 無線驅動程式：確定無線驅動程式是最新狀態。 這有助於降低與過時驅動程式相關的不良用戶體驗。 許多組織在其修補程序迴圈中不包含無線驅動程式，而且這些驅動程式可能會中斷配對數年。 確保無線驅動程式保持在最新狀態，可解決許多無線問題。 WMM：無線多媒體擴充功能 (WMM) ，也稱為 Wi-Fi 多媒體，可為無線網路提供基本的 QoS 功能。 現代化無線網路必須支援許多裝置。 這些裝置會為了頻寬而競爭，並可能導致 VoIP 服務的質量問題，其中的速度和延遲非常重要。 請洽詢您的無線廠商以取得特定資訊，並考慮在您的無線網路上實作WMM，以排定 商務用 Skype 和 Teams 媒體的優先順序。 存取點密度：在理想位置中，存取點可能相隔太遠或不遠。 若要盡量減少潛在的干擾，請在會議室和不受牆壁或其他訊號弱 Wi-Fi 物件遮住的位置放置額外的存取點。 2.4 GHz 與 5 GHz：5 GHz 提供較少的背景干擾和較高的速度，且應優先於透過Wi-Fi 部署 VoIP。 不過，5 GHz 的強度不如 2.4 GHz，而且沒有那麼容易地裝牆。 檢閱您的建築物佈局，以判斷您可以依賴哪一個頻率來獲得最佳連線。 |
| 網路裝置 | 大型組織可能會有數百部裝置分散在網路上。 與您的網路小組合作，確保從使用者到因特網的網路裝置保持在最新狀態。 |
| Vpn | VPN 設備通常並非設計用來處理即時媒體工作負載。 部分 VPN 設定禁止使用 UDP (這是媒體) 慣用的通訊協定，且僅依賴 TCP。 考慮實作 VPN 分割道解決方案，以協助降低 VPN 品質不佳的來源。 |
| 用戶端 僅限 (商務用 Skype Online) |
確定所有客戶端都會定期更新。 |
| 裝置 | 如果裝置是通話品質問題的相關問題，請考慮更新有問題的裝置。 若要深入瞭解，請閱讀 Teams的電話 。 |
| 司機 | 修補網路 (乙太網路和Wi-Fi) 、音訊、視訊及USB驅動程式應為您整體修補程式管理策略的一部分。 更新驅動程式可解決許多質量問題。 |
| Wi-Fi 上的會議室 | 我們強烈建議使用至少 1-Gbps 乙太網路連線，讓會議室裝置連線到網路。 會議室裝置通常包含多個音訊和視訊串流，以及會議內容，例如屏幕畫面分享，而且比其他 Teams 或 商務用 Skype 端點擁有更高的網路需求。 根據定義，會議室是信鄢裝置，Wi-Fi 只能在安裝期間獲得優惠。 會議室必須經過額外的照護和注意處理，以確保使用這些裝置的體驗是會議或超出預期。 會議室的質量問題通常會快速向上呈報，因為資深員工通常會使用這些問題。 除了便利) 之外，所有專案都 (相等，因此 Wi-Fi 效能通常小於有線連線。 隨著「攜帶您自己的裝置」原則的興起以及膝上型計算機的興起，Wi-Fi 存取點往往過度使用。 實時媒體可能不會優先於 Wi-Fi 網路上，這可能會在尖峰使用時間期間導致質量問題。 如此大量的使用情形可能與會議一致，其中可能有十幾個人出席，每個都有自己的膝上型計算機和智慧型手機，都聯機到與會議室裝置相同的 Wi-Fi 存取點。 Wi-Fi 僅應視為暫時解決方案、行動裝置安裝，或 Wi-Fi 已正確布建以支援商務級實時媒體。 |
TCP
TCP) (傳輸控制通訊協定會被視為故障迴轉傳輸，而非實時媒體的主要傳輸。 這是故障後援傳輸的原因，是因為 TCP 的狀態。 例如，如果在延遲的網路上撥打電話，而媒體封包延遲，則幾秒鐘前的封包就不再有用了，就等著頻寬換機到接收器，這會讓情況變糟。 這會讓音訊收發器拼接和伸展音訊，產生音效成品，通常是以抖動的形式出現。
本節中的報告不會區分良好與不佳的串流。 由於偏好 UDP，報告會尋找 TCP 用於音訊、視訊和視訊型螢幕共用 (VBSS) 。 提供低串流速率有助於比較UDP品質與TCP品質，讓您可以專注在影響最大的位置。 TCP 使用量主要是防火牆規則不完整所導致。 如需 Teams 和 商務用 Skype Online 防火牆規則的詳細資訊，請參閱 Microsoft 365 和 Office 365 URL 和 IP 位址範圍。
備註
音訊、視訊和 VBSS 都偏好以 UDP 做為主要傳輸方式。 舊版 RDP 應用程式共用工作負載僅使用 TCP。
TCP 使用量
TCP 報告指出過去七個月的整體 TCP 使用量。 本節中的所有進一步報告將著重於縮小最常使用 TCP 的特定建築物和子網。 會議和兩方串流皆可使用個別的報告。
調查
您可以使用這份報告回答下列問題：
- 當月 TCP 串流的總數量為何？
- 情況是否比上個月差或更好？
- TCP 使用量趨勢是遞增、穩定或減少嗎？
- TCP PSR 是否與我的整體 PSR 相同？
如果您發現 TCP 使用趨勢正在增加或高於一般每月使用量，請利用子報表來尋找任何可能需要修復的建築物或網路，藉此花時間進行調查。 在理想情況下，您希望在受管理的網路上盡可能少 TCP 音訊會話。
TCP 與 UDP
此報告會識別最新月份音訊、視訊和視訊螢幕共用 (VBSS) 的 TCP 與 UDP 使用量報告。
分析
雖然您希望 TCP 盡可能降低使用量，但您可能會在原本良好的部署中看到一些 TCP 使用量。 TCP 本身並不會導致通話不佳，因此會提供串流費率，以協助識別 TCP 使用量是否為品質不佳的參與者。
TCP 調查
在提供的 CQD 範本中，使用受管理的網路或所有網路範本，依建置和子網報告流覽至 TCP Stream。 為了調查 TCP 使用量，程式是相同的，因此我們會將討論重點放在會議上。
修復
此報告會識別導致 TCP 使用量的特定建築物和子網。 另外還會有一份報告，用來識別通話中使用的 Microsoft Relay IP，以協助隔離遺失的防火牆規則。 請將您的修復工作集中於擁有最高 TCP 串流量的建築物上，以最大化影響。
TCP 使用率最常見的原因是防火牆或 Proxy 中缺少例外規則。 我們將在下一節討論 Proxy，因此現在請專注於防火牆。 您可以使用提供的建築物或子網，判斷哪些防火牆需要更新。
| 修復 | 指導方針 |
|---|---|
| 設定防火牆 | 確認您的防火牆中排除 Microsoft 365 或 Office 365 IP 埠和位址。 針對媒體相關的 TCP 問題，請將您最初的工作重點放在下列事項上：
|
| 驗證 | 使用 Microsoft 網路評定工具來檢查特定 Microsoft 365 的連線問題，或 Office 365 受影響建築物或子網的 IP 位址和埠。 |
HTTP Proxy
HTTP Proxy 不是建立媒體會話的慣用路徑，原因有很多。 許多包含深度封包檢查功能，可防止服務連線完成並造成中斷。 此外，幾乎所有 Proxy 都會強制 TCP，而不是允許 UDP，這是針對最佳音訊質量建議。
我們一律建議您設定用戶端以直接連線至 Teams 和 商務用 Skype 服務。 這對媒體流量特別重要。
重要
我們建議您上傳 有效的建築物檔案 ，以便在分析 Proxy 使用量時，與外部音訊串流區別。
HTTP Proxy 使用量
範本此區段中的 HTTP Proxy 串流報表與 TCP 報表非常類似。 這並不會看出通話是否不佳或良好，而是看出通話是否透過 HTTP 連線。
分析
您想要看到盡可能少的 HTTP 媒體串流。 如果您有串流流流覽 Proxy，請洽詢您的網路小組，以確保已設定適當的排除專案，讓用戶端直接路由至 Teams 或 商務用 Skype 在線媒體子網。
如果您的組織只有一個因特網 Proxy，請確認正確的 Microsoft 365 或 Office 365 URL 和 IP 位址範圍排除專案。 如果貴組織已設定多個因特網 Proxy，請使用 HTTP 子報表來隔離受影響的建築物或子網。
對於無法略過 Proxy 的組織，請確定 商務用 Skype 客戶端設定為在 Proxy 後方正確登入，如本文所述，商務用 Skype 應使用 Proxy 伺服器登入，而不是嘗試直接連線。
HTTP Proxy 調查
此報告會識別導致 HTTP 使用量的特定建築物和子網。
修復
我們建議您一律略過 商務用 Skype 和 Teams 的 Proxy，尤其是媒體流量。 Proxy 不會讓 商務用 Skype 更安全，因為其流量已加密。 效能相關問題可透過延遲和封包遺失而引入環境。 這類問題會導致音訊、視訊和螢幕共用的負面體驗，其中即時串流是必要的。
HTTP 使用率最常見的原因是遺失 Proxy 中的例外規則。 您可以使用提供的建築物或子網，快速判斷需要設定哪些 Proxy 才能讓媒體略過。
確認必要的 Microsoft 365 或 Office 365 FQDN 已新增至 Proxy 中的允許清單。
端點調查
本節著重於回報用戶端版本和使用認證裝置的工作。 報告適用於用戶端版本、用戶端類型、 (麥克風) 擷取裝置和驅動程式、視訊擷取裝置，以及 Wi-Fi 廠商和驅動程式版本的使用情況大綱。
備註
本文並未涵蓋範本中包含的所有報告;不過，下列說明的調查方法仍適用。 如需詳細資訊，請參閱個別報告描述。
用戶端版本
這些報告的重點在於識別 商務用 Skype 使用中的用戶端版本及其在環境中的相對磁碟區。
重要
目前，Teams 用戶端會透過 Azure 內容傳遞網路自動發佈和更新，並會由服務保持在最新狀態。 因此，您不需要監控Teams用戶端版本 (，除非您關閉自動更新，我們不建議) 。
除非您排除同盟參與者數據，否則這些報告將包含同盟端點的用戶端遙測。 若要排除同盟端點，您必須新增第二個租用戶標識碼的查詢篩選器，設定為貴組織的 租用戶標識符。 或者，您可以使用 URL 篩選 來排除同盟參與者遙測。
修復
推動高品質用戶體驗的一個重要部分，就是確保受管理的用戶端執行最新版本的 商務用 Skype，以及確保音訊、視訊、網路和 USB 驅動程式是最新版本。 這提供數種優點，包括：
- 管理幾個版本與許多版本比較容易。
- 它提供層級的一致性體驗。
- 這可讓您更輕鬆地針對通話品質和可用性問題進行疑難解答。
- Microsoft 會持續在整個產品中進行一般改良和優化。 確保使用者收到這些更新，可降低他們遇到已解決之問題的風險。
將您的部署限制為小於六個月的用戶端版本，可減少需要支援的版本數量，以改善整體用戶體驗並改善可管理性。
如果您只使用 Office 隨選即用，您會自動在六個月的視窗內。 不需要進一步的動作。
如果您混合使用隨選即用及安裝程式套件 (MSI) ，您可以使用報告來確認 MSI 用戶端是否定期更新。 如果您發現用戶端落後，請與負責管理 Office 更新的小組合作，確保他們定期核准及部署用戶端修補程式。
此外，也請務必考慮並確保網路、視訊、USB 和音訊驅動程式也已修補。 您可以輕易忽略這些驅動程式，而不會將它們包含在修補程式管理原則中。
您可以透過下列連結找到 商務用 Skype 的版本號碼：
裝置
若要使用麥克風裝置報告，我們需要瞭解平均意見分數的概念 (MOS) 。 MOS 是一項金色標準度量，用來測量感知到的音訊品質。 它以 0 到 5 的整數分級表示。
所有語音品質量值的基礎，就是一個人對於語音品質的感知方式。 因為它受到人類感知的影響，因此本身就是主旨。 主旨測試有幾種不同的方法。 大部分的語音品質量值都是根據 ACR) 刻度 (絕對分類分級。
在 ACR 主旨測試中，統計上相當數量的使用者以 1 (不良) 到 5 (次絕佳的) 來評價其經驗品質。 分數的平均值是 MOS。 產生的 MOS 取決於向群組公開的體驗範圍，以及分級的體驗類型。
由於對即時通訊系統進行語音品質的主旨測試是不切實際的，因此 Microsoft Teams 和 商務用 Skype 使用進階演算法來明確預測主旨測試的結果，來產生 MOS 值。
可用的 MOS 和相關聯指表組可讓您檢視由音訊裝置傳遞給使用者的體驗品質。
透過提供具有 Teams 和 商務用 Skype 認證之裝置的使用者，您可以降低因裝置本身 (而發生負體驗的可能性，例如，內建膝上型電腦喇叭和麥克風) 。 如需詳細資訊，請參閱認證 計劃 和 合作夥伴解決方案目錄的這些文章。
裝置報告是用來根據音量和 MOS 分數來評估裝置使用量， (音訊僅) ，而且可以在 [用戶端 & 裝置] 底下的隨附範本中找到。
重要
除非您排除同盟參與者數據，否則這些報告將包含同盟端點的用戶端遙測。 若要排除同盟端點，您必須新增第 二個租用戶標識 碼的查詢篩選器，設定為貴組織的 租用戶標識符。 不過，您可以使用 URL 篩選 來排除同盟參與者遙測。
備註
檢視此報告時，您可能會注意到您看到同一部裝置多次回報。 這是因為回報裝置到 CQD 的方式所導致。 硬體和操作系統地區設定的差異會導致回報裝置數據的方式差異。
修復
一般說來，您必須探索並淘汰非認證的裝置，並以認證的裝置取代它們。 檢閱裝置報告時的一些考慮包括：
- 裝置是否通過 Teams 和 商務用 Skype 的認證？
- 您可以使用 個別使用者通話分析來識別特定裝置的使用者。 檢查以確認他們擁有最新的設備驅動器，而且他們的裝置未透過USB集線器或連接基座連接。
- 正在使用多少種不同版本的驅動程式？ 是否定期修補？ 確保定期修補音訊、視訊和 Wi-Fi 驅動程式，有助於排除這些驅動程式作為質量問題的來源，並讓用戶體驗更可預測且一致。
音訊
下一個工作是決定 認證音訊裝置的整體使用量。 我們建議至少 80% 的所有音訊串流使用通過認證的音訊裝置。 最好的方法是將麥克風裝置報告導出至 Excel，以計算已認證或核准裝置的使用量。 組織通常會保留所有核准裝置的清單，因此篩選和排序數據應該很簡單。
影片
影片驅動程式對於持續更新也很重要。 確保定期修補視頻卡有助於排除視訊驅動程式，做為視訊串流品質不佳的來源。 使用 通過認證的視訊裝置 有助於確保用戶體驗順暢且高品質。 建議使用支援 H.264 原生編碼的視訊裝置，以減少視頻會議期間的 CPU 使用量。
Wi-Fi
Wi-Fi 驅動程式也必須以一般頻率修補，並且應該包含在您的修補程式管理策略中。 許多質量問題都可藉由維護最新的 Wi-Fi 驅動程式來修正。 如需優化 Wi-Fi 基礎結構的詳細資訊，請參閱 本文 Wi-Fi 規劃。