Share via

通話流程拓撲

  • 文章

本文說明 Azure 通訊服務呼叫流程拓撲。 在本文中，您將瞭解 Azure 通訊服務 的網路概念、通話流量的加密方式，以及如需通訊服務通話流程簡介的詳細數據，請瀏覽通話流程概念檔。

背景

網路概念

在檢閱呼叫流程拓撲之前，我們會定義整個文件所參考的一些詞彙。

客戶網路包含您管理的任何網路區段。 這可能包括辦公室內的有線和無線網路，或辦公室、數據中心和因特網服務提供者之間的網路。

客戶網路通常會有數個網路周邊，其中包含強制執行組織安全策略的防火牆和/或 Proxy 伺服器。 建議您執行 完整的網路評量 ，以確保通訊解決方案的最佳效能和品質。

通訊服務網路是支援 Azure 通訊服務 的網路。 此網路由 Microsoft 管理，並透過最接近終端客戶的 Microsoft 擁有資料中心在全球散發。 此網路負責傳輸轉送、群組呼叫的媒體處理，以及其他支援豐富即時媒體通訊的元件。

流量類型

通訊服務主要以兩種類型的流量為基礎： 即時媒體 和 訊號。

實時媒體 會使用即時傳輸通訊協定 （RTP） 傳輸。 此通訊協議支援音訊、視訊和螢幕共用數據傳輸。 此數據對網路等待時間問題很敏感。 雖然可以使用 TCP 或 HTTP 傳輸即時媒體，但建議使用 UDP 作為傳輸層通訊協定，以支援高效能的終端用戶體驗。 透過 RTP 傳輸的媒體承載會使用 SRTP 來保護。

通訊服務解決方案的使用者會從其用戶端裝置連線到您的服務。 這些裝置與伺服器之間的通訊會以 訊號處理。 例如：在裝置與服務之間發出訊號，支援通話起始和即時聊天。 大部分的訊號流量都會使用 HTTPS REST，不過在某些情況下，SIP 可用來做為信號流量通訊協定。 雖然這種類型的流量對延遲較不敏感，但低延遲訊號可讓解決方案的使用者享有愉快的用戶體驗。

媒體加密

Azure 通訊服務 呼叫 SDK 和 Teams 用戶端中的通話流程是以透過 HTTPS 的作業階段描述通訊協定 （SDP） RFC 8866 供應專案和回應模型為基礎。 一旦被呼叫端接受來電，呼叫端和被呼叫者就會話參數達成一致。

媒體流量會加密，並使用安全 RTP（SRTP）在來電者與被呼叫者之間流動，這是即時傳輸通訊協定 （RTP） 的配置檔，可提供對 RTP 流量的機密性、驗證和重新執行攻擊保護。 在大部分情況下，用戶端對用戶端媒體流量會透過用戶端與伺服器連線訊號交涉，並在直接從用戶端到用戶端時使用SRTP進行加密。

Azure 通訊服務 呼叫 SDK 時，會使用 DTLS 來衍生加密密鑰。 當 DTLS 交握完成之後，媒體就會開始透過 SRTP 使用此 DTLS 交涉加密密鑰進行流動。

Azure 通訊服務呼叫 SDK 和 Teams 用戶端時，會使用認證型令牌，透過 TURN 安全地存取媒體轉播。 媒體轉播會透過 TLS 保護的通道交換令牌。

Azure 通訊服務 參與 Azure 通訊服務 音訊、視訊和視訊共用的兩個端點之間的媒體流量會利用 SRTP 來加密媒體串流。 密碼編譯金鑰會透過信號通訊協定在兩個端點之間交涉，該通訊協定會使用 TLS 1.2 和 AES-256（在 GCM 模式中）加密的 UDP/TCP 通道。

呼叫流程原則

有四個一般原則可支撐 Azure 通訊服務 呼叫流程：

  • 通訊服務群組呼叫的第一個參與者會決定呼叫裝載所在的區域。 某些拓撲中有此規則的例外狀況，如下所述。
  • 用來支援通訊服務的媒體端點會根據媒體處理需求來選取，而且不會受到通話中的參與者數目影響。 例如，點對點呼叫可能會使用雲端中的媒體端點來處理媒體進行轉譯或錄製，而具有兩個參與者的通話可能無法使用任何媒體端點。 群組呼叫會使用媒體端點進行混合和路由。 此端點會根據裝載呼叫的區域來選取。 從用戶端傳送到媒體端點的媒體流量可能會直接路由傳送，或者如果客戶網路防火牆限制要求，可能會使用 Azure 中的傳輸轉送。
  • 點對點呼叫的媒體流量會採用可用的最直接路由，假設呼叫不需要雲端中的媒體端點。 慣用的路由會直接傳送至遠端對等互連（用戶端）。 如果無法使用直接路由，一或多個傳輸轉送會轉送流量。 媒體流量不應該跨伺服器，例如封包形狀器、VPN 伺服器或其他可能會延遲處理並降低用戶體驗的功能。
  • 向流量發出訊號時，一律會傳送至最接近使用者的任何伺服器。

若要深入瞭解所選媒體路徑的詳細數據，請參閱 呼叫流程概念檔。

各種拓撲中的呼叫流程

通訊服務（因特網）

此拓撲是由使用雲端通訊服務的客戶使用，而不需要任何內部部署部署，例如 Azure 直接路由。 在此拓撲中，來自通訊服務的流量會透過因特網流動。

Azure 通訊服務 拓撲。

圖 1 - 通訊服務拓撲

上圖上箭號的方向會反映影響企業周邊連線之通訊的起始方向。 如果是媒體的 UDP，第一個封包可能會向反向流動，但這些封包可能會遭到封鎖，直到其他方向的封包流動為止。

流程描述：

  • 流程 2 – 代表客戶網路上使用者起始的流程，做為使用者通訊服務體驗的一部分。 這些流程的範例包括 DNS 和點對點媒體傳輸。
  • Flow 2' – 代表由遠端行動通訊服務使用者起始的流程，以及客戶網路的 VPN。
  • 流程 3 – 代表由遠端行動通訊服務使用者對通訊服務端點起始的流程。
  • 流程 4 – 代表客戶網路上使用者對通訊服務的起始流程。
  • Flow 5 – 代表一個通訊服務用戶與客戶網路內另一個通訊服務用戶之間的點對點媒體流程。
  • Flow 6 – 代表遠端行動通訊服務使用者與另一個透過因特網的遠端行動通訊服務用戶之間的點對點媒體流程。

使用案例：一對一呼叫

一對一通話表示一位使用者直接呼叫另一位使用者。 為了初始化呼叫，呼叫 SDK 會取得一組候選專案，其中包含IP位址和埠，包括本機、轉接和反轉用戶端的公用IP位址，如轉介面所見）。 呼叫端 SDK 會將這些候選項目傳送給被呼叫方;被呼叫方也會取得一組類似的候選專案，並將其傳送給來電者。 STUN 連線檢查訊息可用來尋找哪個呼叫端/呼叫方媒體路徑可運作，並選取最佳工作路徑。 建立連線路徑之後，會透過此連線執行 DTLS 交握，以確保安全性。 在 DTLS 交握之後，SRTP 金鑰會衍生自 DTLS 交握程式。 媒體（也就是使用 SRTP 保護的 RTP/RTCP 封包），然後使用選取的候選組傳送。 傳輸轉送是 Azure 通訊服務的一部分。

如果本機 IP 位址和埠候選專案或反射候選專案具有連線能力，則會針對媒體選取用戶端之間的直接路徑（或使用 NAT）。 如果客戶網路上，則應該選取直接路徑。 這需要客戶網路內的直接 UDP 連線能力。 如果用戶端都是遊牧雲端使用者，則視 NAT/防火牆而定，媒體可能會使用直接連線。

如果一個用戶端位於客戶網路上的內部，而一個用戶端是外部用戶端（例如，行動雲端使用者），則不太可能啟用本機或反射候選者之間的直接連線。 在此情況下，選項是使用任一用戶端的其中一個傳輸轉送候選專案（例如，內部用戶端從 Azure 中的傳輸轉送取得轉送候選專案;外部客戶端必須能夠將 STUN/RTP/RTCP 封包傳送至傳輸轉送）。 另一個選項是內部用戶端傳送至行動雲端用戶端取得的轉送候選專案。 雖然強烈建議使用媒體的 UDP 連線，但支援 TCP。

高階步驟：

  1. 通訊服務使用者 A 會使用 Flow 2 解析 URL 功能變數名稱（DNS）。
  2. 使用者 A 會使用 Flow 4 在 Teams 傳輸轉送上配置媒體轉送埠。
  3. 通訊服務使用者 A 會使用 Flow 4 傳送「邀請」給通訊服務的 ICE 候選專案。
  4. 通訊服務會使用 Flow 4 通知使用者 B。
  5. 使用者 B 會使用 Flow 4 在 Teams 傳輸轉送上配置媒體轉送埠。
  6. 使用者 B 會使用 Flow 4 傳送「回應」與 ICE 候選專案，其會轉送回使用 Flow 4 的使用者 A。
  7. 已選取使用者 A 和使用者 B 叫用 ICE 連線測試，並選取最佳的可用媒體路徑（如需各種使用案例，請參閱下圖）。
  8. 這兩位使用者使用 Flow 4 將遙測傳送至通訊服務。

客戶網路 （內部網路）

客戶網路內的流量流程。

圖 2 - 客戶網路內

在步驟 7 中，已選取點對點媒體流程 5。

此媒體傳輸是雙向的。 Flow 5 的方向表示一端會從連線角度起始通訊。 在此情況下，使用哪個方向並不重要，因為這兩個端點都在客戶網路內。

客戶網路到外部使用者（由 Teams 傳輸轉送轉送的媒體轉送）

一對一通話流程透過轉接。

圖 3 - 客戶網路至外部使用者（由 Azure 傳輸轉送轉送轉送的媒體）

在步驟 7 中，已選取 Flow 4（從客戶網路到通訊服務）和 Flow 3（從遠端行動通訊服務使用者到 Azure 通訊服務）。

這些流程是由 Azure 內的 Teams 傳輸轉送轉送所轉送。

此媒體傳輸是雙向的。 方向指出從連線觀點起始通訊的哪一端。 在此情況下，這些流程會用於使用不同的傳輸通訊協定和位址來發出訊號和媒體。

客戶網路對外部使用者（直接媒體）

一對一呼叫流程與外部使用者。

圖 4 - 客戶網路至外部使用者（直接媒體）

在步驟 7 中，會選取 Flow 2 （從客戶網路到透過因特網對等用戶端的對等互連）。

具有遠端行動使用者的直接媒體（未透過 Azure 轉譯）是選擇性的。 換句話說，您可以封鎖此路徑，以透過 Azure 中的傳輸轉送強制執行媒體路徑。

此媒體傳輸是雙向的。 Flow 2 到遠端行動使用者的方向表示一端會從連線能力的觀點起始通訊。

VPN 使用者到內部使用者（Teams 傳輸轉送轉送的媒體轉送）

透過轉接與 VPN 使用者搭配一對一通話流程。

圖 5 - VPN 使用者至內部使用者（由 Azure 轉送轉送的媒體轉送

VPN 與客戶網路之間的訊號會使用 Flow 2*。 客戶網路與 Azure 之間的訊號使用 Flow 4。 不過，媒體會略過 VPN，並使用 Flow 3 和 4 透過 Azure 媒體轉寄路由傳送。

VPN 使用者到內部使用者（直接媒體）

具有直接媒體 VPN 的一對一通話流程（內部使用者）

圖 6 - VPN 使用者至內部使用者 （直接媒體）

VPN 與客戶網路之間的訊號會使用 Flow 2』。 客戶網路與 Azure 之間的訊號正在使用流程 4。 不過，媒體會略過 VPN，並使用從客戶網路到因特網的流程 2 進行路由傳送。

此媒體傳輸是雙向的。 Flow 2 到遠端行動使用者的方向表示一端會從連線角度起始通訊。

對外部使用者的 VPN 使用者 （直接媒體）

具有直接媒體 VPN 的一對一通話流程（外部使用者）

圖 7 - 外部使用者的 VPN 使用者（直接媒體）

VPN 使用者到客戶網路之間的訊號會使用 Flow 2* 和 Flow 4 至 Azure。 不過，媒體會略過 VPN，並使用 Flow 6 路由傳送。

此媒體傳輸是雙向的。 Flow 6 到遠端行動使用者的方向表示一端會從連線能力的觀點起始通訊。

使用案例：透過通訊服務主幹對 PSTN 的通訊服務用戶端

通訊服務允許從公用電話交換網（PSTN）撥打和接聽電話。 如果 PSTN 主幹是使用通訊服務提供的電話號碼進行連線，則此使用案例沒有特殊的連線需求。 如果您想要將自己的內部部署 PSTN 主幹連線到 Azure 通訊服務，您可以使用 Azure 直接路由（可在 CY2021 中使用）。

與 PSTN 參與者進行一對一通話

圖 8 – 透過 Azure 主幹將通訊服務用戶傳送至 PSTN

在此情況下，從客戶網路到 Azure 的訊號和媒體會使用 Flow 4。

使用案例：通訊服務群組呼叫

音訊/視訊/螢幕共用 （VBSS） 服務是 Azure 通訊服務 的一部分。 它有公用IP位址，必須可從客戶網路連線，而且必須可從 Nomadic Cloud 用戶端連線。 每個用戶端/端點都必須能夠連線到服務。

內部用戶端會以與一對一呼叫所述的相同方式取得本機、反射和轉送候選專案。 用戶端會在邀請中將這些候選專案傳送至服務。 服務不會使用轉寄，因為它具有可公開連線的IP位址，因此會以其本機IP位址候選回應。 用戶端和服務會以一對一呼叫所述的相同方式檢查連線能力。

Azure 通訊服務 群組通話

圖 9 – 通訊服務群組呼叫

互操作性限制

流經 Azure 通訊服務 的媒體受限如下：

與 PSTN 界限上的第三方工作階段邊界控制器 （SBC） 應終止使用 SRTP 保護的 RTP/RTCP 數據流，而不是將它轉接至下一個躍點。 如果您將流程轉接至下一個躍點，可能無法瞭解。

第三方 SIP Proxy 伺服器。 使用第三方 SBC 和/或閘道發出 SIP 信號的通訊服務可能會周遊 Microsoft 原生 SIP Proxy（就像 Teams 一樣）。 不支援與第三方 SIP Proxy 的互操作性。

第三方 B2BUA （或 SBC）。 來自 PSTN 的通訊服務媒體流程由第三方 SBC 終止。 不支援與通訊服務網路內第三方 SBC 的互操作性（其中第三方 SBC 會調解兩個通訊服務端點）。

不支持的技術

VPN 網路。 通訊服務不支援透過 VPN 進行媒體傳輸。 如果您的使用者使用 VPN 用戶端，客戶端應該透過非 VPN 連線分割媒體流量，如啟用 Lync 媒體以略過 VPN 通道中所 指定。

注意

雖然標題指出 Lync，但適用於 Azure 通訊服務 和 Teams。*

封包形狀器。 不支援封包擷取、封包檢查或封包成形裝置，而且品質可能會大幅降低。

下一步

開始使用通話

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