本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 在 VDI 環境中使用 Amazon Connect
<a name="using-ccp-vdi"></a>

虛擬桌面基礎架構 (VDI)環境會為您的解決方案增添另一層複雜性，需要單獨的 POC 作業並將效能測試最佳化。 聯絡控制面板 (CCP) 可在複雜型、精簡型和極簡型用戶端 VDI 環境運作，正如其他以 WebRTC 為基礎的瀏覽器應用程式，而組態/支援/最佳化最好由您的 VDI 支援團隊處理。雖然如此，以下仍提出對我們 VDI 型客戶有幫助的考量和最佳實務。

## 使用分割 CCP 模型
<a name="use-split-ccp"></a>

建議使用分割 CCP 模型搭配在 VDI 中執行的無媒體 CCP，以及在本機 PC 上攜帶媒體的 CCP。您可以建立沒有應用程式資料和通話發訊媒體的 CCP，以使用 Amazon Connect Streams API 建置自訂 CCP。如此一來，媒體會使用標準 CCP 傳遞至本機桌面，而資料和通話控制會傳遞至與無媒體 CCP 的遠端連線。如需有關 Streams API 的詳細資訊，請參閱 GitHub 儲存庫 [https://github.com/aws/amazon-connect-streams](https://github.com/aws/amazon-connect-streams)。

**注意**  
**Firefox 使用者**：如果您在分割模式下使用 VDI，則無法在 VDI 外部針對 CCP 使用 Firefox 瀏覽器。CCP 會遵循 Firefox 麥克風使用指引，而且只有在 CCP 標籤成為焦點時，才具有連線至使用者麥克風的存取權。

下圖顯示客服工作站如何由本機瀏覽器和虛擬桌面組成。它透過 WebRTC 連線至 Amazon Connect，並透過 VDI 連線來連線至公司虛擬基礎設施。

![客服工作站、虛擬桌面、公司虛擬基礎設施和 Amazon Connect。](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/use-split-ccp.png)


## 雲端桌面
<a name="use-cloud-desktops"></a>

如果您使用 Citrix、Amazon WorkSpaces 或 Omnissa 雲端桌面，您可以建立新的客服使用者介面或更新現有的客服使用者介面，例如自訂 CCP，以將音訊處理卸載至客服的本機裝置，並自動將音訊重新導向至 Amazon Connect。這樣可以在具有挑戰性的網路上獲得更簡化的客服人員體驗，並改善音訊品質。若要開始使用，您可以使用 [Amazon Connect 開放原始碼程式庫](https://github.com/amazon-connect/amazon-connect-streams)，以建立新的客服使用者介面或更新現有的客服使用者介面，例如自訂 CCP。

## 設計 VDI 環境時的考量事項
<a name="considerations-vdi"></a>
+ **客服人員的位置**–在理想情況下，使用 CCP 的客服人員位置和 VDI 主機位置之間的跳轉次數與往返時間要盡量降至最低。
+ **VDI 解決方案的主機位置**–在理想情況下，VDI 主機位置應與客服人員位於相同的網路區段，且來自內部資源和邊緣路由器的跳轉次數均應降至最低。而到 WebRTC 和 Amazon EC2 範圍端點的往返時間也應降至最低。
+ **網路**–流量在端點之間經歷的每次跳轉，都會增加故障的可能性並提高延遲的機會。如果基本路由未最佳化，或者管道不夠快速或寬廣，VDI 環境就特別會發生通話品質問題。雖然 Direct Connect 可以改善從邊緣路由器到 的呼叫品質 AWS，但無法解決內部路由問題。您可能需要升級或最佳化您的私有 LAN/WAN，或重新導向到外部裝置，避免通話音訊問題。在大部分情況下，如果需要這麼做，則 CCP 不會是唯一發生問題的應用程式。
+ **專用資源**–建議於網路和桌面層級採用，避免備份和大型檔案傳輸之類活動影響可用的客服人員資源。防止資源爭用的其中一種方式，是針對以類似方式使用環境的 Amazon Connect 使用者限制桌面存取，而非與可能以不同方式使用這些資源的其他業務單位共用資源。
+ **透過遠端連線使用軟體電話**–這在 VDI 環境中可能會導致音訊品質受到影響。
**提示**  
如果您的客服人員會連接至遠端端點並在該環境中作業，我們建議將音訊重新路由至外部 E.164 端點，或者透過本機裝置連接媒體，再經由遠端連線發出訊號。