共用方式為

網路建議

  • 發行項

本文摘要說明網路環境會如何影響語音和視訊通話品質。 許多因素都有助於 Azure 通訊服務即時媒體的品質，其中包括音訊、視訊和應用程式共用。 其中一些因素，包括網路品質與頻寬、防火牆、主機和裝置設定。

網路品質

透過 IP 即時媒體質量受到基礎網路連線品質的重大影響，尤以受到下列數量所影響：

  • 延遲。 網路上從點 A 到點 B 取得 IP 封包的所需時間。 此網路傳播延遲取決於兩點之間實體距離，以及流量流經該裝置所產生的任何額外負荷。 延遲會以單向或來回時間 (RTT) 進行測量。
  • 封包遺失。 在特定時間範圍內遺失的封包百分比。 封包遺失會直接影響音訊品質 — 從幾乎沒有影響的小量、個別的遺失封包，到導致音訊完全中斷的連續高載遺失。
  • 封包間抵達抖動，亦稱為抖動。 連續封包之間的平均延遲變更。 Azure 通訊服務可以透過緩衝處理來適應某些層級的抖動。 只有在抖動超過參與者會注意到其效果緩衝之際。

網路頻寬

請確定您的網路已設定為支援並行 Azure 通訊服務媒體工作階段與其他商務應用程式所需要的頻寬。 針對頻寬瓶頸測試端對端網路路徑，對於成功部署多媒體 Azure 通訊服務的解決方案至關重要。

下列頻寬需求適用於 JavaScript SDK。

頻寬 案例
40 Kbps 對等音訊通話
500 Kbps 對等音訊通話和螢幕畫面分享
500 Kbps 在 30 FPS 的對等品質視訊通話為 360 像素
1.2 MBps 在 30 FPS 的對等 HD 品質視訊通話，其解析度為 HD 720 像素
500 Kbps 在 30 FPS 的群組視訊通話為 360 像素
1.2 MBps 在 30 FPS 的 HD 群組視訊通話，其解析度為 HD 720 像素
1.5 Mbps 在 30 FPS 的對等 HD 品質視訊通話，其解析度為 HD 1080 像素

下列頻寬需求適用於原生 Windows、Android 和 iOS 的 SDK。

頻寬 案例
30 KBps 對等音訊通話
130 Kbps 對等音訊通話和螢幕畫面分享
500 Kbps 在 30 FPS 的對等品質視訊通話為 360 像素
1.2 MBps 在 30 FPS 的對等 HD 品質視訊通話，其解析度為 HD 720 像素
1.5 Mbps 在 30 FPS 的對等 HD 品質視訊通話，其解析度為 HD 1080 像素
500 Kbps/1 Mbps 群組視訊通話
1 Mbps/2 Mbps HD 群組視訊通話，1080 像素畫面上的 540 像素影片

防火牆設定

Azure 通訊服務連線需要特定埠和 IP 位址的網際網路連線，以提供高品質多媒體的體驗。 若無法存取這些連接埠和 IP 位址，通訊服務將無法正常運作。 需要開啟的 IP 範圍和允許列出的網域清單如下：

類別 IP 範圍或 FQDN 連接埠
媒體流量 Azure 公用雲端 IP 位址的範圍 20.202.0.0/16。上述範圍是媒體處理器或 Azure 通訊服務 TURN 服務上 IP 位址的範圍。 UDP 3478 至 3481、TCP 通訊埠 443
訊號、遙測、註冊 *.skype.com、*.microsoft.com、*.azure.net、*.azure.com、*.office.com TCP 443, 80

下列端點應僅可供美國政府 GCC High 客戶存取。

類別 IP 範圍或 FQDN 連接埠
媒體流量 52.127.88.0/21, 52.238.114.160/32, 52.238.115.146/32, 52.238.117.171/32, 52.238.118.132/32, 52.247.167.192/32, 52.247.169.1/32, 52.247.172.50/32, 52.247.172.103/32, 104.212.44.0/22, 195.134.228.0/22 UDP 3478 至 3481、TCP 通訊埠 443
訊號、遙測、註冊 *.gov.teams.microsoft.us, *.infra.gov.skypeforbusiness.us, *.online.gov.skypeforbusiness.us, gov.teams.microsoft.us TCP 443, 80

網路最佳化

下列工作為選擇性，且不需要推出 Azure 通訊服務。 請使用此指導方針將您的網路和 Azure 通訊服務效能達到最佳化，或在您知道有些網路限制存在時使用。 如果有以下情況，建議進一步最佳化：

  • Azure 通訊服務執行緩慢。 可能沒有足夠的頻寬。
  • 通話會斷斷續續。 斷續情形可能是因防火牆或 Proxy 封鎖程式而造成。
  • 通話出現靜電干擾以及切斷，或是聽起來像機器人語音。 這些問題可能是因為抖動或封包遺失而造成。
網路​​最佳化工作 詳細資料
規劃您的網路 在此文件中，可取得通話的網路最低限度需求。 請參閱 Scrum 小組範例，以規劃您的網路。
外部名稱解析 請確定執行 Azure 通訊服務 SDK 的所有電腦，都可以解析外部 DNS 查詢，以探索 Azure 通訊服務人員所提供的服務，而您的防火牆亦不會防止存取。 確定 SDK 可以解析該位址 *.skype.com、*.microsoft.com、*.azure.net、*.azure.com 和 *.office.com。
維護工作階段持續性 請確定您的防火牆不會變更對應的網路位址轉譯 (NAT) 位址或 UDP 的連接埠。
驗證 NAT 集區大小 驗證使用者連線所需的 NAT 集區大小。 當多個使用者和裝置使用 NAT 或連接埠位址平移來存取 Azure 通訊服務時，請確定每個可公開路由 IP 位址後隱藏之裝置不會超過所支援的號碼。 請確定已將適當的公用 IP 位址指派給 NAT 集區，以避免連接埠耗盡。 連接埠耗盡會導致內部使用者和裝置無法連線至 Azure 通訊服務。
入侵偵測和防護指導 如果您的環境已部署入侵偵測系統或入侵防護系統，以提供輸出連線的額外安全性層級，請允許所有 Azure 通訊服務 URL。
設定分割通道 VPN 請提供 Scrum 小組流量的替代路徑，以略過虛擬私人網路 (VPN)，通常稱其為分割通道 VPN。 分割通道表示 Azure 通訊服務的流量不會通過 VPN，而是直接至 Azure。 略過 VPN 會對媒體質量產生正面影響，並降低來自 VPN 裝置和組織的網路負載。 若要實作分割通道 VPN，請與 VPN 廠商合作。 建議略過 VPN 其他的原因：
  • VPN 通常不是設計或設定為支援即時媒體。
  • VPN 亦可能不支援 Azure 通訊服務所需的 UDP。
  • VPN 亦會在已加密的媒體流量上引進額外的加密圖層。
  • 由於透過 VPN 裝置的針腳流量，對 Azure 通訊服務連線可能沒有效率。
實作 QoS 使用服務品質 (QoS) 來設定封包優先順序。 QoS 可改善通話品質，並協助您監視並疑難排解通話品質。 QoS 應該在受控網路的所有區段上進行實作。 即使網路已足夠佈建頻寬，QoS 仍會在未預期的網路事件發生時提供風險降低。 使用 QoS 時會優先處理語音流量，讓這些非預期的事件不會對通話品質造成負面影響。
Wi-Fi 最佳化 與 VPN 類似，Wi-Fi 網路不一定設計或設定以支援即時媒體。 規劃或最佳化 Wi-Fi 網路以支援 Azure 通訊服務的是高品質部署的重要考量。 請考慮下列因素：
  • 實作 QoS 或 Wi-Fi 多媒體，以確保媒體流量會適切地優先取得您的 Wi-Fi 網路。
  • 規劃並最佳化 Wi-Fi 訊號以及存取點放置。 2.4-GHz 範圍可能會依據存取點放置而提供適當的體驗，但存取點通常會受到在其範圍內運作的其他取用者裝置影響。 5-GHz 範圍由於其密集範圍而較適合即時媒體，但需要更多存取點才能取得足夠涵蓋範圍。 端點亦需要支援該範圍，並設定為據以使用這些訊號的範圍。
  • 如果您使用雙頻 Wi-Fi 網路，請考慮實作訊號範圍控制。 訊號範圍控制是由 Wi-Fi 廠商實作的技術，其會影響雙頻用戶端而使用 5-GHz 範圍。
  • 當相同通道的存取點太接近時，可能會導致訊號重疊而不小心競爭，這會導致使用者體驗降低。 請確定彼此旁邊的存取點位於沒有重疊的通道上。
每個無線廠商都有自己建議要部署無線的解決方案。 如需特定指導，請諮詢您的 Wi-Fi 廠商。

作業系統和瀏覽器 (適用於 JavaScript SDK)

Azure 通訊服務語音和視訊 SDK 支援某些特定的作業系統和瀏覽器。 瞭解通話概念文件中呼叫 SDK 支援的作業系統和瀏覽器。

下一步

您可能會對下列文章感興趣：