Microsoft Teams 中的媒體質量和網路連線效能
重要
由中國 21Vianet 營運的 商務用 Skype Online 將於 2023 年 10 月 1 日淘汰。 如果您尚未升級 商務用 Skype 在線用戶,系統會自動排程他們進行協助升級。 如果您想要將組織自行升級至 Teams,我們強烈建議您立即開始規劃升級路徑。 請記住,成功升級會使技術和使用者整備一致,因此請務必在您流覽 Teams 旅程時運用我們的 升級指導方針 。
商務用 Skype Online 已在 2021 年 7 月 31 日淘汰,但不包括由中國 21Vianet 所營運的服務。
本文定義Microsoft Teams 服務的一組網路效能需求,以及如何根據您對網路連線能力的評估,選擇使用因特網或 ExpressRoute 來連線至您的網路和Microsoft Teams。 如果您已決定針對 Microsoft 365 或 Office 365 部署 Azure ExpressRoute 專用連線,本檔也會提供如何在不同Microsoft Teams 部署案例中規劃 ExpressRoute 連線的指導方針。
透過IP Real-Time 媒體 (音訊、視訊及應用程式共用) 的品質,會受到端對端網路連線品質的極大影響。 為了達到最佳Microsoft Teams 媒體品質,請務必確保您的公司網路與 Microsoft Teams 之間有高質量的連線。 達成此目標的最佳方式是根據您的網路容量來設定內部網路和雲端連線,以容納所有聯機Microsoft Teams 的尖峰流量。
Azure ExpressRoute 並不需要Microsoft 365 和 Office 365 服務,包括 Microsoft Teams。 不過,Azure ExpressRoute 是可用的部署選項之一,可協助確保Microsoft 365 或 Office 365 的連線符合 Microsoft Teams 網路效能需求,並確保最優化Microsoft Teams 媒體質量體驗。
提示
雖然本主題提供您整體網路效能指導方針,但完整的網路評估指導方針不在本檔的範圍之外。 若要尋找可協助您進行網路效能測量的Microsoft Teams 合作夥伴清單,做為徹底且完整的網路評估的一部分,請造訪 商務用 Skype 合作夥伴解決方案]。
Microsoft Teams 的網路連線需求
影響 Teams 媒體品質Microsoft因素
有許多不同的因素會Microsoft Teams Real-Time 媒體 (音訊、視訊和應用程式共用) 品質,包括使用的裝置、環境和網路連線能力。
裝置
在 Real-Time 媒體會話中,所有參與者所使用的媒體擷取和轉譯裝置,例如耳機和網路攝影機,都會對整體音訊和視訊質量產生重大影響。 低品質的裝置或配備不正確設備驅動器的裝置會降低音訊的整體音質,以及降低視訊的影像品質。 認證的裝置或品質良好的裝置可協助回音取消、噪音篩選、視訊解析度及減少延遲。
雖然不需要經過認證的音訊和視訊媒體裝置,但針對 Microsoft Teams 認證強烈建議的裝置,以獲得最佳媒體體驗。 如需所有Microsoft Teams 認證裝置的清單,請 參閱Microsoft Teams 認證的 Android 裝置。 您可以使用 商務用 Skype 系統管理中心所找到的MicrosoftTeams 通話品質儀錶板,以確認使用中的裝置是否正常運作,並監控音訊和視訊媒體品質。
提示
需要經過認證的裝置,才能獲得最佳 商務用 Skype 媒體質量體驗。
請務必記住,任何媒體裝置、Microsoft Teams 用戶端,以及 商務用 Skype 伺服器 Real-Time 媒體流經這些服務,會帶來一些延遲。 裝置和軟體處理延遲以及網路延遲對端對端整體延遲以及用戶的體驗有重大影響,並有助於提升端對端的整體延遲。
環境
用戶開會及使用音訊和視訊裝置的環境和周圍區域,是音訊和視訊品質的另一大因素。 從吵雜環境中撥號的使用者會收到聲響、低音量和不清楚的音訊。 在深色或低光線環境中的用戶無法產生明亮、清晰的視訊影像品質。 在會議室設定中,麥克風和視訊裝置的位置會直接影響參與者收到的音效和影像品質。
若要更清楚瞭解使用者的音訊和視訊體驗,請使用 商務用 Skype 應用程式工具>選項>音訊裝置或視訊裝置,對使用中的裝置進行變更並自定義其設定。
網路
透過IP網路 Real-Time 媒體的品質受到網路連線品質的極大影響,尤其是受到以下情況的影響:
延遲 這是從 A 點取得 IP 封包到網路上指向 B 所需的時間。 此網路傳播延遲與兩點之間的實體距離和光速系結在一起,包括兩者之間各種路由器所佔用的額外負荷。 延遲是以 RTT) (單向或往返時間來測量。
封包遺失 這通常定義為在指定時間範圍中遺失的封包百分比。 封包遺失會直接影響音訊品質,從幾乎沒有影響的小型、個別遺失封包,到造成完整音訊完全中斷的連續中斷。
封包間送達抖動或只是抖動 這是連續封包之間延遲的平均變更。 包括 Microsoft Teams 在內的大多數新式 VoIP 軟體都可以透過緩衝來適應某些程度的抖動。 只有當抖動超過緩衝時,參與者才會注意到抖動的效果。
注意事項
緩衝抖動會增加端對端延遲。
擁有許多並行Microsoft Teams Real-Time 媒體會話,以及其他Microsoft 365 或 Office 365 服務及其他商務應用程式所產生的其他網路流量,確保整個網路路徑有足夠的頻寬將您的網路連線至Microsoft Teams 服務,對於避免網路壅塞以及確保媒體 (音頻的絕佳媒體 Real-Time 至關重要。 視訊和應用程式共用) 品質。
跨擁擠的網路實作服務品質 (QoS)
此外,網路上的流量圊塞會大幅影響媒體品質。 若要讓音訊和視訊封包能夠更快速地瀏覽網路,並優先於擁擠的網路中的其他網路流量,您可以使用服務品質 (QoS) ,以協助為音訊和視訊通訊提供最佳的用戶體驗。
QoS 可讓您將較高的優先順序指派給包含音訊或視訊數據的網路封包。 藉由指派較高的優先順序給這些封包,音訊和視訊通訊可能會比涉及檔傳輸、網頁瀏覽或資料庫備份等事項的網路會話更快速地透過網路傳輸,且中斷較少。 這是因為根據預設,用於檔傳輸或資料庫備份的網路封包會被指派「最佳工作量」做為優先順序,而且網路囑塞不會造成太大的影響。 如果您沒有將較高的優先順序指派給媒體 (音訊、視訊及應用程式共用) 封包,並將這些專案指派為「最佳作法」,也會與所有其他網路流量一起處理。 視網路囑塞的程度而定,這可能會為您的用戶帶來較低的整體音訊和視訊質量體驗。
強烈建議您在網路上實作 QoS,以確保網路內的網路塞不會受到影響。 不過,若要讓這影響最大,所有網路端點都必須支援 QoS,這表示所有端點都必須優先於 QoS 標記和封包優先順序。 Microsoft Teams 服務遵守Microsoft網路中的 QoS 標記和優先順序。 不過,透過因特網等公用連線從公司網路路由至Microsoft網路的流量,並不會保留 QoS 標記和封包優先順序。 使用 Azure ExpressRoute 從您的網路到 Microsoft 365 或 Office 365 的私人連線,會提供保留 QoS 標記和封包優先順序的部署解決方案,進而提高使用者的整體音訊和視訊品質。
線上到 Microsoft Teams 的網路效能需求
商務用 Skype Real-Time 媒體會在許多不同的裝置、用戶端應用程式、伺服器軟體,以及跨不同網路之間傳輸。 Real-Time 媒體的端對端延遲是所有元件和網路區段所引入的總延遲量。 端對端網路連線的品質是由品質最差的網路區段所決定。 此區段做為此網路流量的瓶頸。
下圖說明會議中的單向音訊流程,從一位Microsoft Teams 參與者到另一位參與者。
在此會議案例中,媒體路徑包含下列網路區段:
從使用者 1 到Microsoft網路邊緣的連線 這通常包括網路連線,例如WiFi或乙太網路、從使用者1到因特網出口點的WAN連線 (您的網路Edge裝置) ,以及從您的網路Edge到Microsoft網路Edge的因特網連線。
Microsoft網路內的連線 這是在使用 A/V 會議伺服器的 Microsoft Edge 到 Microsoft Teams 資料中心之間。
Microsoft網路內的連線 這介於 Microsoft Teams 數據中心和Microsoft網路 Edge 之間。
從Microsoft網路邊緣連線到使用者 2 這包括從您的網路 Edge 到 Microsoft 網路 Edge 的因特網連線、從使用者 2 到網路 Edge (網路 Edge) 的因特網出口點連線,以及 WiFi 或乙太網路等網路連線。
下圖顯示 Microsoft Teams PSTN 通話的元件和網路區段明細:
在 PSTN 通話案例中,媒體路徑會跨越下列網路區段:
從 商務用 Skype 用戶端來電者連線到Microsoft網路的邊緣這通常包括網路連線,例如WiFi或乙太網路、從 商務用 Skype客戶端來電者到因特網出口點的WAN 連線, (您的網路Edge裝置) ,以及從您的網路Edge到Microsoft網路 Edge 的因特網連線。
Microsoft網路內的連線 這是在 Microsoft Edge 到 Microsoft Teams 數據中心之間,其中會使用中移伺服器。
Microsoft網路內的連線 這介於 Microsoft Teams 數據中心和Microsoft網路 Edge 之間。
Microsoft網路與 PSTN 服務提供者合作夥伴之間的連線這是連線存在,用來從Microsoft網路外部的 商務用 Skype 客戶端撥打 PSTN 電話。
從 商務用 Skype 用戶端到Microsoft網路Edge的網路效能需求
為了達到最佳 商務用 Skype 媒體品質,從公司網路連線到Microsoft網路 Edge 的連線需要下列網路效能指派目標或閾值。 此網路區段包含您的內部網路,包括所有WiFi和乙太網路連線、透過WAN連線的任何公司網站對網站流量,例如 Multiprotocol Label Switching (MPLS) ,以及與Microsoft網路 Edge 的因特網或 ExpressRoute 合作夥伴連線。
謹慎
公司網路上 商務用 Skype 用戶端與Microsoft 365 或 Office 365 服務之間的連線,必須符合下列網路效能需求和臨界值。
度量 | 最佳的 | 窮 |
---|---|---|
往返時間 (RFC 3550) | < 60 ms | > 500 ms |
RFC 3550 (封包遺失) 上限 | < 5% | > 25% |
平均封包遺失 (RFC 3550) | < 0.5% | > 10% |
封包抖動 (RFC 3550) | < 3 ms | > 30 ms |
其他效能目標需求:
Microsoft網路在全球擁有超過 160 個 Edge 位置。 我們透過這些Edge網站與全球 (ISP 的主要因特網服務提供者合作) 。 延遲計量目標假設您的公司網站或網站以及Microsoft Edge 位於同一洲。
您的公司網站或Microsoft網路 Edge 連線的網站包括第一個躍點網路存取,可以是WiFi或其他無線技術。
網路效能目標假設有適當的頻寬和/或服務質量規劃。 換句話說,當網路連線在尖峰負載之下時,這會直接套用至 商務用 Skype Real-Time 媒體流量。
測量網路效能
若要測量從任何公司網路網站到網路 Edge 的實際網路效能,尤其是延遲和封包遺失,您可以使用像 ping 等工具,針對從Microsoft Edge 和數據中心網站執行的一組 商務用 Skype 媒體轉送服務進行測試。
注意事項
透過 ping (ICMP) 測量網路效能無效。 因此,從 2020 年 1 月開始,以下任何公開的廣播 IP 都會停止回應 ICMP 要求。 若要有效測量網路執行效能,Microsoft建議使用 網路設定工具。
若要測試Microsoft網路的因特網連線,建議您針對下列 商務用 Skype 媒體轉送的VIP進行測試。 Anycast VIP 會解析為最接近測試位置之Microsoft網路 Edge 網站中媒體轉送的 IP 位址。
IP位址 |
類型 |
位置 |
---|---|---|
13.107.8.2 |
貴賓 |
World Wide Anycast IP |
以下是評估網路效能的一些高層級建議:
您應該評估您的內部網路以及Microsoft 365 或 Office 365 的連線。
您應該在很長一段時間內評估並收集您所有網路的數據。 我們建議您至少執行一周的網路效能測試,以便查看所有工作日和時數的使用模式。 這會顯示尖峰時間。
您應該對多個網路效能測量範例進行測量。 我們建議您在收集數據的整個期間內,從公司網站每 10 分鐘進行一次測量。 若要比較 Microsoft Teams 網路效能需求,請從此範例數據集中取得第 90 個百分位數度量值。
您應該持續評估網路效能。 由於使用模式變更、使用大量頻寬的新企業型應用程式,以及貴組織或實體公司位置的變更,因此網路使用率會隨著時間而不同。 請務必根據這些網路效能需求和目標/臨界值持續監視您的網路效能,並及時調整以確保最佳 Real-Time 媒體品質。
使用 Azure VM 測量網路效能
除了針對Microsoft網路 Edge 網站進行測試,商務用 Skype 客戶和合作夥伴針對 Microsoft Azure 雲端服務使用測試設定的網路評估解決方案。 在這些解決方案中,網路評估工具會針對設定為 Azure 雲端服務的自定義端點測試延遲、封包遺失和抖動。 因此,測試網路流量會流經另一個網路區段,也就是網路邊緣與主控網路評定服務的 Azure 數據中心之間的Microsoft網路內部連線。
針對那些基於 Azure 託管測試服務的網路評估解決方案。 建議您在國家/或地區內執行網路評估。 例如,針對美國東部的客戶網站,評定應針對 Azure 的東部美國數據中心地區所託管的測試服務實例執行。
以下是針對 Azure 服務型網路評估設定的延遲 (RTT) 目標。 單向延遲目標會是對應 RTT 目標的一半。 封包遺失和抖動目標會與Skype媒體轉送根據測試定義的目標相同。
客戶地區 |
Azure 地區 |
您的網路 Edge - (RTT) 的 Azure 來回時間 |
您的網站 - Azure 來回時間 (RTT) |
---|---|---|---|
美國中央 |
美國中央 |
99 |
139 |
美國東部 |
美國東部 |
86 |
126 |
美國中北方 |
美國中北方 |
97 |
137 |
美國中南部 |
美國中南部 |
94 |
134 |
美國西部 |
美國西部 |
94 |
134 |
夏威夷美國 |
美國西部 |
116 |
156 |
加拿大中央 |
加拿大中央 |
138 |
178 |
加拿大東部 |
加拿大東部 |
131 |
171 |
北歐洲 |
北歐洲 |
99 |
139 |
西歐 |
西歐 |
95 |
135 |
東亞 |
東亞 |
118 |
158 |
東南亞 |
東南亞 |
97 |
137 |
日本東部 |
日本東部 |
111 |
151 |
日本西部 |
日本西部 |
118 |
158 |
巴西南部 |
巴西南部 |
70 |
110 |
澳大利亞東部 |
澳大利亞東部 |
124 |
164 |
澳大利亞南 |
澳大利亞南 |
124 |
164 |
印度中地區 |
印度中地區 |
103 |
143 |
南印度 |
南印度 |
103 |
143 |
西印度 |
西印度 |
103 |
143 |
中國東部 |
中國東部 |
120 |
160 |
中國北方 |
中國北方 |
120 |
160 |
媒體品質和 ExpressRoute
Azure ExpressRoute for Microsoft 365 或 Office 365 是專用的網路連線,可連線至 Microsoft 365 或 Office 365。 它可讓客戶控制其網路流量所採用的路徑。 他們不再需要擔心因特網上會發生無法預測的路由,因為因特網上的數據是由未知電信業者、提供者和 ISP 所攜帶。 透過 ExpressRoute 傳送的網路流量會直接透過 ExpressRoute 合作夥伴的網路傳送至Microsoft的網路。 這可讓客戶將 Microsoft 365 或 Office 365 視為位於其專屬連線的網站外數據中心。
Azure ExpressRoute 適用於所有 Microsoft 365 和 Office 365 授權方案。 不過,Microsoft 365 和 Office 365 需要 Azure ExpressRoute 進階版附加元件,才能啟用全域路由。 擁有至少 500 個基座且正在實作 ExpressRoute 的客戶,可以免費取得必要的 ExpressRoute 進 階版附加元件。
需要 ExpressRoute 才能獲得良好的媒體品質嗎?
Azure ExpressRoute 並不是取得最優化Microsoft Teams 媒體品質的需求。 不過,這是其中一個部署選項,可協助您確保雲端連線符合 商務用 Skype 網路效能目標或閾值。
Microsoft 365 和 Office 365 是使用因特網的高效能和安全服務。 我們將繼續投資新的安全性功能和地區Edge節點,以持續改善安全性與效能。 Azure ExpressRoute 並不需要Microsoft 365 或 Office 365 服務,包括 Microsoft Teams。 Azure ExpressRoute 是可用的其中一個部署選項,可協助確保連線至 Microsoft 365 或 Office 365 符合 商務用 Skype 網路效能需求,並確保最佳Microsoft Teams 媒體質量體驗。
針對Microsoft Teams 媒體品質,請務必滿足從 商務用 Skype 用戶端 Microsoft到網路 Edge 的網路效能需求,以及網路 Edge 與 Microsoft Microsoft網路邊緣之間的連線符合效能目標,
此外,也請務必讓貴公司的實體網路連線能力,包括您的內部網路和雲端連線能力,以容納尖峰媒體流量。 Azure ExpressRoute 是協助客戶確保其Microsoft Teams 雲端連線符合所有這些效能需求的眾多方式之一。
語音品質 SLA 需要 ExpressRoute 嗎?
否,Microsoft Teams 語音品質 SLA 不需要 ExpressRoute。 Microsoft Teams 語音品質 SLA 適用於任何Microsoft Teams 語音服務使用者在正確授權和訂閱內撥打的任何合格通話,可讓該使用者撥打任何類型的 VoIP 或 PSTN 通話。 語音品質 SLA 應包含下列所有條件都已解決:
來自Microsoft認證 IP 電話的電話。
有線乙太網路連線。
因網路問題Microsoft語音質量問題。
注意事項
語音品質 SLA 會排除那些通話中通話品質偏低的問題,這些通話是由包括 ExpressRoute 合作夥伴及其他網路在內的非Microsoft網路中的問題所造成。
因特網或 Azure ExpressRoute?
在決定要Microsoft Teams 的網路連線選項之前,客戶必須根據網路效能需求中所述的網路效能需求來評估其網路和目前的因特網連線能力, 才能連線到 Microsoft Teams。
如果目前因特網連線的網路效能在尖峰時段設定為足夠的容量,而且符合網站到網路Edge Microsoft以及從網路Edge到網路Edge Microsoft網路 Edge 的網路效能,您可以繼續使用現有的因特網聯機來連線到 Microsoft Teams。
對於不符合網路效能需求的公司網站,我們強烈建議您先與現有的網路服務提供者合作,以改善整體網路效能。 不過,如果仍未滿足,使用 Azure ExpressRoute 可協助確保您的 Microsoft Teams 雲端連線可協助您符合網路效能需求。
Azure ExpressRoute 提供下列額外權益:
SLA (服務等級協定) 您的網路與Microsoft網路之間的連線可用性。 ExpressRoute 的可用性 SLA 保證為 99.9%。
Microsoft 365 和 Office 365 服務所需的已規劃和保證頻寬。 您可以使用 ExpressRoute 只傳送 Microsoft 365、Office 365 或 商務用 Skype 流量,然後讓所有其他因特網流量透過您網路的其他因特網出口/出口點來達到此目的。
ExpressRoute 的設計目的是在您的網路和Microsoft網路之間保留 DSCP QoS 標記。
如需 ExpressRoute QoS 和容量規劃的詳細資訊,請參閱 Microsoft Teams 中的 ExpressRoute 和 QoS。
我是否可以設定僅適用於 Microsoft Teams 的 Azure ExpressRoute?
是的,您可以設定 Azure ExpressRoute,以確保從公司網路到僅Microsoft Teams 的極佳網路連線。 這將為您的使用者提供最佳 Real-Time 媒體品質,但您可以接著繼續連線到其他Microsoft 365 或透過因特網 Office 365 服務。
[框線網關通訊協定] (BGP) 是因特網上的路由通訊協定,用於在因特網上路由網路流量。 其設計目的是要在網 (系統之間交換路由資訊,) 透過因特網找到。 BGP 社群值是可套用至內送或外寄路由的屬性標記。 BGP 社群常用來向接收的 AS 訊號訊號,這是輸出連結,以根據地理位置、服務類型或其他準則來連線到指定的目的地。
在 BGP 社群支援下,Microsoft會根據其所屬的服務,以適當的 BGP 社群值來標記前綴和路由。 Microsoft會以適當的 BGP 社群值標記透過公用對等和Microsoft對等公告的前綴,指出前綴裝載於該區域。 您可以仰賴社群的值來做出適當的路由決策,以提供最佳路由。 您可以使用 Microsoft Teams BGP 社群值來設定僅適用於 Microsoft Teams 的 ExpressRoute 連線。 您可以在 ExpressRoute 路由需求瞭解更多資訊。
Microsoft Teams 的 ExpressRoute 連線案例
如果您已根據上述建議決定 ExpressRoute 適合您,以下是您應取得 ExpressRoute 連線的位置和數量建議。
僅限在線部署 - 單一網站
如果您所有的使用者都使用 Microsoft Teams 服務,而且您的辦公室是以單一實體位置為中心,而您決定要部署 Azure ExpressRoute,您應該在公司網站之間設定單一 ExpressRoute 連線到最接近 的 ExpressRoute 對等位置。
下圖顯示這類部署的範例。 在這個範例中,Contoso 是一所位於 FL 的索里特大學。 Contoso 有 10,000 名教職員和學生。 因特網會從其位置測試至Microsoft Edge 網站在尖峰課程時段顯示超過 5% 的封包遺失。 他們決定使用含超額布建頻寬的 Microsoft 365 或 Office 365 專用連線,以便避免Microsoft 365 或 Office 365 尤其是針對 Microsoft Teams Real-Time 流量的網路壅塞。 他們透過位於洛杉磯,GA MeetMe 網站的 ExpressRoute 連線至Microsoft雲端。
僅限在線部署 - 同一洲的多個網站
如果您的公司使用來自相同地區或洲中多個辦公室的 Microsoft Teams 服務,而您選擇實作 Azure ExpressRoute,建議您透過 ExpressRoute 連線您的主網站,然後選擇性地針對不符合建議網路效能目標的其他位置新增額外的 ExpressRoute 對等功能。
在下列範例中,Contoso 是一家美國旅遊服務公司,其總部位於紐約,但在 美國 間有其他辦公室。 他們的辦公室透過使用 MPLS 連線至 Microsoft 365 或 Office 365 的 WAN 連線。 他們最初是在紐澤西島 Hoboken 的因特網路由器設定 ExpressRoute 連線到紐約 MeetMe 網站。
透過這項設定,從大多數網站到Microsoft網路 (紐約Edge網站的網路流量) 可以符合網路效能需求中所述的 商務用 Skype 客戶端連線網路效能目標,從 商務用 Skype 用戶端到Microsoft網路 Edge。 不過,Contoso 的西岸辦公室與紐約之間的延遲已超過 50 毫秒。 此外,Honolulu 是 Contoso 的第二大辦公室,從 Honolulu 到紐約的延遲超過 80 毫秒。 為了確保這些辦公室的用戶擁有良好的媒體品質,Contoso 決定在其聖荷里網站與 Silicon Valley ExpressRoute MeetMe 網站之間新增西岸 ExpressRoute 連線。
僅限在線部署 - 不同洲的多個網站
如果您所有的使用者都使用 Microsoft Teams 服務,而且您的辦公室位於多個洲的多個實體位置,如果您決定部署 Azure ExpressRoute,您應該針對每個洲的主要網站與最接近 的 ExpressRoute 對等位置,為每個洲設定至少一個 ExpressRoute 聯機。 視成本與權益而定,您可以選擇從無法達到網路效能目標的網站部署其他 ExpressRoute 連線。
在下列範例中,Contoso 是一家大型公司法務公司,在 北美洲 和歐洲的大城市設立辦公室。 根據他們的因特網連線及其內部網路效能評估,Contoso 決定在 北美洲 部署兩個 ExpressRoute 連線,併為其所有歐洲辦公室部署單一 ExpressRoute 迴路。
混合式部署
如果您有內部部署的 Lync 或 Microsoft Teams 部署,並選擇實作混合式Microsoft Teams 整合,建議您,如果您決定部署 Azure ExpressRoute,每個內部部署 Lync 或 Microsoft Teams Edge 網站至少必須有一個 ExpressRoute 連線,而且每個洲都有辦公室至少一個 ExpressRoute 連線。 視成本與權益而定,您可以針對每個洲選擇從無法達到網路效能目標的辦公室部署額外的 ExpressRoute 連線。
如果您有內部部署Microsoft Teams 部署,您必須遵循 Edge Server規劃與部署指南。 具體來說,Edge 伺服器必須從您的網路外部連線。 這通常會透過指派可路由的公用IP位址到Edge伺服器,或使用網路位址翻譯 (NAT) 來達成。
在下列範例中,Contoso 有一個現有的內部部署 Microsoft Teams 企業版 語音部署。 他們想要將內部部署使用者移轉到 Microsoft 365 或 Office 365 線上服務。 他們也決定使用混合式部署,以便繼續為所有內部部署和在線使用者使用現有的 PSTN 基礎結構。 Contoso 的內部部署數據中心和 商務用 Skype Edge Server 位於芝加哥。 針對他們的部署,Contoso 決定在其芝加哥數據中心和芝加哥 ExpressRoute 之間設定一個 ExpressRoute 連線。 他們也新增了西岸 ExpressRoute 連線,以更有效地為他們的 Honolulu 辦公室提供服務。
使用雲端連接器版本進行在線部署
商務用 Skype Cloud Connector Edition 是由一組套套裝 虛擬機器 (VM) 所組成的混合式方案,可實作內部部署 PSTN 連線。 藉由在虛擬環境中部署最低 商務用 Skype Server 拓撲,您就可以透過現有的內部部署 PSTN 語音基礎結構,透過有線電話和行動電話來傳送和接聽電話。
如果您決定部署 Azure ExpressRoute 和雲端連接器版本,建議您為每一洲之間的每個洲,設定至少一個快速路由連線到最接近 的 ExpressRoute 對等位置。 視成本與權益而定,您可以針對每個洲選擇從無法達到網路效能目標的網站部署其他 ExpressRoute 連線。
如果您有內部部署Microsoft Teams 部署,您必須遵循 商務用 Skype Cloud Connector Edition 規劃指南。 具體來說,Access Edge 和 A/V Edge 服務應指派公用 IP 位址,並可連線至 Microsoft 365 或 Office 365 數據中心。
在下列範例中,Contoso 是一家位於幾個主要歐洲國家/地區和城市的歐洲會計公司。 當他們針對所有共同作業需求註冊 Microsoft Teams 時,決定為每個具有實體位置的國家/地區放置雲端連接器,以繼續使用其 PSTN 基礎結構和現有的電信業者合約。 根據他們從所有網站和網路Edge Microsoft測試,他們判斷倫敦中的單一ExpressRoute連線可協助達成從 商務用 Skype 用戶端到Microsoft網路Edge的網路效能需求中所述的Microsoft Teams 用戶端連線網路效能目標。
以下是 Contoso 的另一個部署選項。 在此情況下,他們決定在部署雲端連接器的每個網站設定 ExpressRoute 連線。