Azure 直接路由基礎結構需求

發行項
04/26/2024

本文說明基礎結構、授權和工作階段邊界控制器 (SBC) 連線的詳細資料，規劃 Azure 直接路由部署時會用到這些資訊。

基礎結構需求

下表列出部署 Azure 直接路由所需的受支援 SBC、網域基礎結構需求，以及其他網路連線需求：

基礎結構需求	您需要下列項目
工作階段邊界控制器 (SBC)	支援的 SBC。如需詳細資訊，請參閱支援的 SBC。
連接到 SBC 的電話語音主幹	一或多個連接到 SBC 的電話語音主幹。在一端，SBC 會透過直接路由連接到 Azure 通訊服務。 SBC 也可以連接到第三方電話語音實體，例如 PBX、類比電話語音配接器。任何連接到 SBC 的公用交換電話網路 (PSTN) 連線選項。 (若要設定 SBC 的 PSTN 主幹，請參閱 SBC 廠商或主幹提供者的說明。)
Azure 訂用帳戶	您用來建立通訊服務資源的 Azure 訂用帳戶，以及 SBC 的設定和連線。
通訊服務存取權杖	若要進行呼叫，您需要具有 `voip` 範圍的有效存取權杖。請參閱存取權杖
SBC 的公用 IP 位址	可用來連線到 SBC 的公用 IP 位址。根據 SBC 的類型，SBC 可以使用 NAT。
SBC 的完整網域名稱 (FQDN)	如需詳細資訊，請參閱 SBC 憑證和網域名稱。
SBC 的公用 DNS 項目	將 SBC FQDN 對應至公用 IP 位址的公用 DNS 項目。
SBC 的公用受信任憑證	SBC 用於所有與 Azure 直接路由通訊的憑證。如需詳細資訊，請參閱 SBC 憑證和網域名稱。
SIP 訊號和媒體的防火牆 IP 位址和連接埠	SBC 會與雲端中的下列服務通訊：負責處理訊號的 SIP Proxy 負責處理媒體的媒體處理器這兩項服務在 Microsoft Cloud 中有專屬的 IP 位址，本文稍後會說明。

SBC 憑證和網域名稱

Microsoft 建議您透過憑證簽署要求 (CSR) 來要求 SBC 的憑證。如需如何為 SBC 產生 CSR 的具體說明，請參閱 SBC 廠商提供的互連指示或文件。

注意

大部分憑證授權單位 (CA) 要求私密金鑰大小至少為 2048。產生 CSR 時請記住這一點。

憑證的 SBC FQDN 須與一般名稱 (CN) 或主體別名 (SAN) 欄位一致。憑證應該直接由憑證授權單位核發，而不是中繼提供者。

或者，通訊服務直接路由支援在 CN 和/或 SAN 中使用萬用字元，且萬用字元須符合標準 RFC HTTP Over TLS。

原來就使用 Office 365 且已在 Microsoft 365 系統管理中心註冊網域的客戶，可以使用相同網域的 SBC FQDN。

以使用 *.contoso.com 為例，它符合 SBC FQDN sbc.contoso.com，但不符合 sbc.test.contoso.com。

注意

Azure 通訊服務直接路由中的 SBC FQDN，必須與 Teams 直接路由中的 SBC FQDN 不同。

通訊服務只信任屬於 Microsoft 受信任的根憑證計畫合作對象的憑證授權單位 (CA) 所簽署的憑證。請確定您的 SBC 憑證是由屬於該計畫的 CA 簽署，且憑證的增強金鑰使用方法 (EKU) 延伸模組包含伺服器驗證。深入了解：

計畫需求 - Microsoft 受信任的根憑證計畫

包含的 CA 憑證清單

重要

Azure 通訊服務直接路由僅支援 TLS 1.2。若要避免服務受到任何影響，請確定 SBC 已設為支援 TLS1.2，而且可以使用 SIP 訊號的下列任意加密套件進行連線：

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 即 ECDHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 即 ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 即 ECDHE-RSA-AES256-SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 即 ECDHE-RSA-AES128-SHA256

僅支援 SRTP 媒體 AES_CM_128_HMAC_SHA1_80。

SBC 配對功能可在通訊服務資源層級運作。這表示您可以將多個 SBC 配對至單一通訊服務資源。不過無法將單一 SBC 與多個通訊服務資源配對。需要唯一的 SBC FQDN 才能配對到不同的資源。

如果 SBC 上的直接路由連線已啟用相互 TLS (MTLS) 支援，則必須在直接路由 TLS 內容的 SBC 信任根存放區中安裝 Baltimore CyberTrust Root 和 DigiCert 全域根 G2 憑證。 (這是因為 Microsoft 服務憑證使用的是這兩個根憑證的其中之一。)若要下載這些根憑證，請參閱 Office 365 加密鏈結。如需詳細資訊，請參閱 Office TLS 憑證變更。

SIP 訊號：FQDN

通訊服務直接路由的連接點為以下三個 FQDN：

sip.pstnhub.microsoft.com - 全域 FQDN - 必須首先嘗試。當 SBC 傳送解析此名稱的要求時，Microsoft Azure DNS 伺服器會傳回 IP 位址，指向指派給 SBC 的主要 Azure 資料中心。系統會以資料中心的效能計量和與 SBC 的地理鄰近性為基礎進行指派。傳回的 IP 位址會對應至主要 FQDN。
sip2.pstnhub.microsoft.com - 次要 FQDN - 地理位置對應至優先順序第二的區域。
sip3.pstnhub.microsoft.com - 第三 FQDN - 地理位置對應至優先順序第三的區域。

依序需要這三個 FQDN 用於：

提供最佳體驗 (藉由查詢第一個 FQDN，指派負載較低且最接近 SBC 的資料中心)。
從 SBC 連線到發生暫時性問題的資料中心時，提供容錯移轉機制。如需詳細資訊，請參閱容錯移轉機制。

sip.pstnhub.microsoft.com、sip2.pstnhub.microsoft.com 和 sip3.pstnhub.microsoft.com 這幾個 FQDN 會解析為下列其中一個 IP 位址：

52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)
52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)

為這些 IP 位址範圍開啟防火牆連接埠，允許傳入和傳出流量進出該位址以傳送訊號。

SIP 訊號：連接埠

使用下列連接埠進行通訊服務 Azure 直接路由：

交通流量	從	至	來源連接埠	目的地連接埠
SIP/TLS	SIP Proxy	SBC	1024–65535	在 SBC 上定義
SIP/TLS	SBC	SIP Proxy	在 SBC 上定義	5061

SIP 訊號的容錯移轉機制

SBC 會執行 DNS 查詢來解析 sip.pstnhub.microsoft.com。系統會根據 SBC 位置和資料中心效能計量來選取主要資料中心。如果主要資料中心發生問題，SBC 會嘗試使用 sip2.pstnhub.microsoft.com，解析為第二個指派資料中心，而在兩個區域中的資料中心都無法使用的罕見情況下，SBC 會重試最後一個 FQDN (sip3.pstnhub.microsoft.com)，以提供第三資料中心 IP。

媒體流量：IP 和連接埠範圍

媒體流量會流向和流出名為媒體處理器的獨立服務。媒體流量的 IP 位址範圍與訊號相同：

52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)
52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)

連接埠範圍

下表顯示媒體處理器的連接埠範圍：

交通流量	從	至	來源連接埠	目的地連接埠
UDP/SRTP	媒體處理器	SBC	49152–53247	在 SBC 上定義
UDP/SRTP	SBC	媒體處理器	在 SBC 上定義	49152–53247

注意

Microsoft 建議 SBC 上的每個同時呼叫至少使用兩個連接埠。

媒體流量：媒體處理器地理位置

媒體處理器會置於與 SIP Proxy 相同的資料中心：

NOAM (美國中南部、兩個位於美國西部和美國東部資料中心)
歐洲 (西歐、北歐、瑞典、法國中部)
亞洲 (新加坡資料中心)
日本 (四本東部和西部資料中心)
澳大利亞 (澳大利亞東部和東南部資料中心)
拉丁美洲 (巴西南部)
非洲 (南非北部)

媒體流量：轉碼器

SBC 與雲端媒體處理器之間的 Leg。

工作階段邊界控制器與雲端媒體處理器之間 Leg 上的 Azure 直接路由介面，可以使用下列轉碼器：

SILK、G.711、G.722、G.729

從供應項目中排除不需要的轉碼器，就可以在工作階段邊界控制器上強制使用特定轉碼器。

通訊服務通話 SDK 應用程式與雲端媒體處理器之間的 Leg

在雲端媒體處理器與通訊服務通話 SDK 應用程式之間的 Leg 上，會使用 G.722。我們目前正努力新增更多轉碼器。

Share via