Azure 通訊閘道與 Microsoft Teams 直接路由的互操作性概觀

Azure 通訊閘道是 Microsoft Teams 直接路由的認證 SBC，可讓電信操作員為客戶提供來自 Microsoft Teams 的 PSTN 連線能力。 Azure 通訊閘道可以操作訊號和媒體，以符合您的網路和 Microsoft 電話 系統的需求，其可支援 Microsoft Teams 直接路由。

在本文章中，您將了解：

• Azure 通訊閘道適合您網路的位置。
• Azure 通訊閘道如何支援許多客戶。
• 它所提供的訊號和媒體互動功能。

網路中的角色和位置

Azure 通訊閘道位於固定線路網路的邊緣。 它會將此網路連線到 Microsoft 電話 系統，讓您支援 Microsoft Teams 直接路由。 下圖顯示 Azure 通訊閘道位於您的網路中的位置。

透過 Microsoft 電話 系統和 Azure 通訊閘道，從 Microsoft Teams 用戶端的通話流向您的網路。

符合認證的 SBC 規格

Azure 通訊閘道支援 Microsoft 規格，適用於 Microsoft Teams 直接路由的認證 SBC。 如需認證和這些規格的詳細資訊，請參閱 通過直接路由認證的會話邊界控制器。

Azure 通訊閘道包含多個功能，可讓您的網路符合直接路由的需求，包括：

• 識別 Microsoft 電話 系統的客戶租使用者
• SIP 互動
• 媒體互動

使用 Microsoft Teams 多租使用者模型支援多個客戶

Azure 通訊閘道部署的設計目的是支援許多租使用者的直接路由。 其設計可讓您提供 Microsoft Teams 通話服務給許多客戶，每個客戶都有許多使用者。 它會使用 Microsoft Teams 檔中所述的 電信業者租使用者和客戶租使用者模型，以設定多個租使用者的會話邊界控制器。 在此模型中：

• 您自己的 Microsoft Teams 設定定義於組織的租使用者中： 電信業者租使用者。
• 每個客戶都有自己的 客戶租使用者，代表該客戶的設定。

建立 Azure 通訊閘道部署時，一律會收到 FQDN （完整功能變數名稱）。 您可以使用此 FQDN 作為 電信業者租使用者的基底網域 。

Azure 通訊閘道也會接收基底網域的兩個每個區域子域（每個區域一個）。

每個客戶都需要 每個區域網域的客戶子域 。 Azure 通訊閘道在傳送至 Microsoft 電話 系統之每個訊息的 [連絡人] 標頭中包含下列其中一個子域：子域的存在可讓 Microsoft 電話 系統識別每個訊息的客戶租使用者。 如需詳細資訊，請參閱識別 Microsoft 電話 系統的客戶租使用者。

對於每個客戶，您必須：

1. 選擇適當的客戶特定 DNS 標籤，以形成子域。
   • 卷標長度必須最多 為 9 個字元，且只能包含字母、數位、底線和虛線。
   • 您不得使用通配符子域或子域搭配多個捲標。
   • 例如，您可以設定標籤 contoso。

   重要

   完整的客戶子域（包括每個區域功能變數名稱）必須最多 48 個字元。 Microsoft Entra ID 不支持超過 48 個字元的功能變數名稱。 例如，客戶子域 contoso1.1r1.a1b2c3d4e5f6g7h8.commsgw.azure.com 是 48 個字元。

2. 使用這項資訊設定 Azure 通訊閘道，作為 Azure 通訊閘道號碼管理入口網站和布建 API 中可用「帳戶」設定的一部分。
3. 遵循 Microsoft Teams 檔，在客戶租用戶中註冊子域名稱，與客戶連絡以更新其租 使用者。

在安排客戶租使用者的更新時，您必須在您所控制的 DNS 伺服器上建立包含驗證碼的 DNS 記錄（由 Microsoft 365 提供，當客戶以功能變數名稱更新其租使用者時提供）。 這些記錄可讓 Microsoft 365 確認客戶租用戶已獲授權使用功能變數名稱。 Azure 通訊閘道會提供您必須使用的 DNS 伺服器。 您必須從客戶取得驗證碼，並使用號碼管理入口網站（預覽版）或布建 API（預覽版）將其上傳至 Azure 通訊閘道。 此步驟可讓 Azure 通訊閘道產生驗證網域的 DNS TXT 記錄。

如需指示，請參閱 使用 Azure 通訊閘道管理 Microsoft Teams 直接路由客戶和號碼。

支援來電者標識碼檢測

Microsoft Teams 直接路由可讓客戶系統管理員將任何電話號碼指派給其租使用者中的使用者，即使您未在網路中將該號碼指派給他們也一樣。 缺乏驗證會產生呼叫端標識符詐騙的風險。

為了防止來電者標識符詐騙，Azure 通訊閘道會篩選來自 Microsoft Teams 的所有直接路由通話。 此檢測可確保客戶只能撥打您指派給號碼的來電。 不過，您可以根據每個客戶停用此檢測，作為「帳戶」設定的一部分，可在數位管理入口網站 （預覽） 和布建 API 中取得。

下圖顯示指派給客戶之號碼的 INVITE 通話流程。 在此情況下，Azure 通訊閘道的數位組態也包含自定義標頭組態，因此 Azure 通訊閘道會新增具有內容的自定義標頭。

下圖顯示來自未指派給客戶號碼的 INVITE 通話流程。 Azure 通訊閘道會拒絕 403 的通話。

識別 Microsoft 電話 系統的客戶租使用者

Microsoft 電話 系統會使用郵件聯繫人標頭中的網域來識別每個訊息的租使用者。 Azure 通訊閘道會自動將訊息上的連絡人標頭重寫為 Microsoft 電話 系統，使其包含適當的個別客戶網域。 此程式可移除核心網路在數位與個別客戶網域之間對應的需求。

您必須布建 Azure 通訊閘道，並將每個號碼指派給客戶進行直接路由。 此布建會使用 Azure 通訊閘道的布建 API （預覽） 或數位管理入口網站 （預覽）。

下圖顯示 Azure 通訊閘道如何重寫從操作員網路傳送至具有直接路由之 Microsoft 電話 系統的聯繫人標頭。

SIP 訊號

Azure 通訊閘道會自動交錯呼叫以支援直接路由的需求，包括：

• 更新聯繫人標頭以正確路由訊息，如識別 Microsoft 電話 系統的客戶租使用者中所述。
• SIP over TLS。
• X-MS-SBC 標頭（描述 SBC 函式）。
• SDP 主體中 a= 屬性行的嚴格規則。
• 通話轉移處理的嚴格規則。

這些功能是 Azure 通訊閘道 符合 Microsoft Teams 直接路由認證 SBC 規格 的一部分。

您可以透過提出 Azure 通訊閘道的支援要求，在初始網路設計中或隨時安排更多互動功能。 例如，您可能需要下列專案的額外互動設定：

• 進階 SIP 標頭或 SDP 訊息操作。
• 支援可靠的臨時訊息 （100rel）。
• 早期和晚期媒體之間的互動。
• 與帶 DTMF 音調互動。
• 將唯一租使用者標識碼放在 SIP 訊息的其他地方，讓您的網路更容易取用，例如參數。tgrp

Microsoft 電話 系統需要以 E.164 格式撥打 （A-） 和撥打 （B-） 電話號碼。 這項需求同時適用於 SIP 和 TEL 號碼。 我們建議您將網路設定為對所有數位使用 E.164 格式。 如果您的網路無法將數字轉換成 E.164 格式，請連絡您的上線小組，或提出支援要求來討論數字轉換的需求。

網路與 Azure 通訊閘道之間的 SIP 主幹是多租使用者，這表示來自您所有客戶的流量共用相同的主幹。

RTP 和 SRTP 媒體

Microsoft 電話 系統通常需要媒體的SRTP。 Azure 通訊閘道同時支援 RTP 和 SRTP，而且可以在它們之間進行互動。 Azure 通訊閘道提供進一步的媒體操作功能，可讓您的網路與 Microsoft 電話系統互操作。

呼叫的媒體處理

部署 Azure 通訊閘道時，您必須選取您想要支援的編解碼器。

Microsoft Teams 直接路由要求核心網路在通話轉移期間支援迴響音調（響鈴音）。 核心網路也必須支持舒適雜訊。 如果您的核心網路無法符合這些需求，Azure 通訊閘道可以將媒體插入呼叫中。

媒體互動選項

Azure 通訊閘道提供多個媒體互動選項。 例如，您可能需要：

• RTCP 的變更處理。
• 控制頻寬配置。
• 優先處理服務品質的特定媒體流量。

如需 Azure 通訊閘道中可用媒體互動功能的完整詳細數據，請提出支援要求。

Microsoft 電話 系統媒體略過支援 （預覽）

Azure 通訊閘道具有直接路由媒體旁路的預覽支援。 直接路由媒體略過可讓媒體在某些案例中直接在 Azure 通訊閘道與 Microsoft Teams 用戶端之間流動，而不是一律透過 Microsoft 電話 系統傳送。 媒體會繼續流經 Azure，因為 Azure 通訊閘道和 Microsoft 電話 系統都位於 Azure 中。

如果您認為媒體略過支援 （預覽） 對您的部署很有用，請與 Microsoft 代表討論您的需求。

下一步

• 瞭解如何 監視 Azure 通訊閘道。
• 瞭解如何 要求變更 Azure 通訊閘道。