本文說明基礎結構、授權和會話邊界控制器 (SBC) 連線詳細資訊，您在計劃 Azure 直接路由部署時需要謹記。
基礎結構需求
下表列出所支援 SBC、網域和其他部署 Azure 直接路由的網路連線需求基礎結構需求：
| 基礎結構需求 | 您需要下列項目 |
|---|---|
| 工作階段邊界控制器 (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） 延伸模組包含伺服器驗證。 瞭解更多資訊：
這很重要
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 上為 Teams 連線啟用了相互 TLS（MTLS）支援，則必須將 Azure 憑證授權單位詳細資料頁面中「根憑證授權單位」區段所列的所有 CA，安裝至 Teams TLS 內容的 SBC 受信任根存放區中。 （這是因為 Microsoft 服務憑證使用這些根憑證。） 欲下載根憑證，請參閱 Microsoft 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 連線到發生暫時性問題的資料中心時，提供容錯移轉機制。 如需詳細資訊，請參閱容錯移轉機制。
FQDN — sip.pstnhub.microsoft.com、sip2.pstnhub.microsoft.com 和 sip3.pstnhub.microsoft.com — 解析為下列其中一個 IP 位址：
52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)52.122.0.0/15 (IP addresses from 52.122.0.0 to 52.123.255.255)
為這些 IP 位址範圍開啟防火牆連接埠，允許傳入和傳出流量進出該位址以傳送訊號。
SIP 訊號：連接埠
使用下列埠進行通訊服務 Azure 直接路由：
| 交通 | 從 | 至 | 來源連接埠 | 目的地連接埠 |
|---|---|---|---|---|
| SIP/TLS | SIP 代理 | SBC | 1024–65535 | 在 SBC 上定義 |
| SIP/TLS | SBC | SIP 代理 | 在 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。 在這個階段新增更多編解碼器的工作正在進行中。