本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
在 VDI 環境中使用 Amazon Connect
虛擬桌面基礎架構 (VDI)環境會為您的解決方案增添另一層複雜性，需要單獨的 POC 作業並將效能測試最佳化。 聯絡控制面板 (CCP) 可在複雜型、精簡型和極簡型用戶端 VDI 環境運作，正如其他以 WebRTC 為基礎的瀏覽器應用程式，而組態/支援/最佳化最好由您的 VDI 支援團隊處理。雖然如此，以下仍提出對我們 VDI 型客戶有幫助的考量和最佳實務。
使用分割 CCP 模型
我們建議使用分割 CCP 模型，搭配在 VDI 中執行的無媒體 CCP 和在本機 PC 上攜帶媒體的 CCP。您可以使用 Amazon Connect Streams API 建置自訂 CCP，方法是建立不含應用程式資料和呼叫訊號媒體的 CCP。如此一來，媒體就會使用標準 CCP 交付至本機桌面，資料和通話控制則透過無媒體 CCP 交付至遠端連線。如需有關 Streams API 的詳細資訊，請參閱 GitHub 儲存庫 https://github.com/aws/amazon-connect-streams
注意
Firefox 使用者：如果您在分割模式下使用 VDI，則無法在 VDI 外部使用適用於 CCP 的 Firefox 瀏覽器。CCP 符合 Firefox 麥克風用量指引，而且只有在 CCP 標籤成為焦點時，才具有連線至使用者麥克風的存取權。
下圖顯示代理程式工作站如何由本機瀏覽器和虛擬桌面組成。它透過 WebRTC 連接到 Amazon Connect，並透過 VDI 連接連接到公司虛擬基礎設施。
雲端桌面
如果您使用 Citrix 或 Amazon WorkSpaces 雲端桌面，您可以建立新的或更新現有的代理程式使用者介面，例如自訂 CCP，以將音訊處理卸載到代理程式的本機裝置，並自動將音訊重新導向至 Amazon Connect。這樣可以在具有挑戰性的網路上獲得更簡化的客服人員體驗，並改善音訊品質。若要開始使用，您可以使用 Amazon Connect 開放原始碼程式庫
設計 VDI 環境時的考量事項
-
客服人員的位置–在理想情況下，使用 CCP 的客服人員位置和 VDI 主機位置之間的跳轉次數與往返時間要盡量降至最低。
-
VDI 解決方案的主機位置–在理想情況下，VDI 主機位置應與客服人員位於相同的網路區段，且來自內部資源和邊緣路由器的跳轉次數均應降至最低。而到 WebRTC 和 Amazon EC2 範圍端點的往返時間也應降至最低。
-
網路–流量在端點之間經歷的每次跳轉，都會增加故障的可能性並提高延遲的機會。如果基本路由未最佳化，或者管道不夠快速或寬廣，VDI 環境就特別會發生通話品質問題。雖然 AWS Direct Connect 可以改善從邊緣路由器到 的呼叫品質 AWS，但它不會解決內部路由問題。您可能需要升級或最佳化您的私有 LAN/WAN，或重新導向到外部裝置，避免通話音訊問題。在大部分情況下，如果需要這麼做，則 CCP 不會是唯一發生問題的應用程式。
-
專用資源–建議於網路和桌面層級採用，避免備份和大型檔案傳輸之類活動影響可用的客服人員資源。防止資源爭用的其中一種方式，是針對以類似方式使用環境的 Amazon Connect 使用者限制桌面存取，而非與可能以不同方式使用這些資源的其他業務單位共用資源。
-
透過遠端連線使用軟體電話–這在 VDI 環境中可能會導致音訊品質受到影響。
提示
如果您的客服人員會連接至遠端端點並在該環境中作業，我們建議將音訊重新路由至外部 E.164 端點，或者透過本機裝置連接媒體，再經由遠端連線發出訊號。
