Azure Communications Gateway と Microsoft Teams ダイレクト ルーティングの相互運用の概要

Azure Communications Gateway は、Microsoft Teams ダイレクト ルーティングの認定 SBC であり、通信事業者が Microsoft Teams から顧客に PSTN 接続を提供できるようにします。 Azure Communications Gateway は、シグナリングとメディアを操作して、ネットワークおよび (Microsoft Teams ダイレクト ルーティングを支える) Microsoft Phone System の要件を満たすことができます。

この記事では、次の内容について解説します:

  • Azure Communications Gateway のネットワーク内の位置。
  • Azure Communications Gateway が多くの顧客をサポートする方法。
  • Azure Communications Gateway が提供するシグナリングとメディアの相互運用機能。

重要

Azure Communications Gateway を使用するには、通信事業者である必要があります。

ネットワーク内の役割と位置

Azure Communications Gateway は、固定回線ネットワークの端に位置します。 その固定回線ネットワークを Microsoft Phone System に接続し、Microsoft Teams ダイレクト ルーティングをサポートできるようにします。 次の図は、Azure Communications Gateway がネットワーク内のどこに位置するかを示しています。

Microsoft Teams Direct Routing 用の Azure Communications Gateway のアーキテクチャ図。

通話は、Microsoft Teams クライアントから Microsoft 電話システムと Azure Communications Gateway を介してネットワークにフローします。

認定 SBC 仕様への準拠

Azure Communications Gateway では、Microsoft Teams ダイレクト ルーティング用の認定 SBC の Microsoft 仕様がサポートされています。 認定とこれらの仕様の詳細については、「ダイレクト ルーティングが認定されたセッション ボーダー コントローラー」を参照してください。

Azure Communications Gateway には、ネットワークがダイレクト ルーティングの要件を満たせるようにするための次のような複数の機能が含まれています。

Microsoft Teams マルチテナント モデルを使用した複数の顧客のサポート

Azure Communications Gateway のデプロイは、多くのテナントのダイレクト ルーティングをサポートするように設計されています。 その設計により、それぞれが多くのユーザーを持つ多数の顧客に Microsoft Teams 通話サービスを提供できます。 Azure Communications Gateway は、「複数のテナントにセッション ボーダー コントローラーを構成する」というタイトルの Microsoft Teams ドキュメントで説明されているキャリア テナントと顧客テナントのモデルを使用します。 このモデルの内容:

  • Microsoft Teams の独自の構成は、組織のテナント (キャリア テナント) で定義されます。
  • 各顧客には、その顧客の構成を表す独自の顧客テナントがあります。

Azure Communications Gateway のデプロイは、作成時に常に FQDN (完全修飾ドメイン名) を受け取ります。 この FQDN をキャリア テナントのベース ドメインとして使用します。

また、Azure Communications Gateway は、ベース ドメインのリージョンごとのサブドメインを 2 つ (リージョンごとに 1 つ) 受け取ります。

各顧客は、これらのリージョンごとのドメインの顧客サブドメインを必要とします。 Azure Communications Gateway は、Microsoft Phone System に送信する各メッセージの Contact ヘッダーにこれらのサブドメインの 1 つを含めます。サブドメインの存在により、Microsoft Phone System は各メッセージの顧客テナントを識別できます。 詳細については、「Microsoft 電話システムの顧客テナントの特定」を参照してください。

顧客ごとに、次の手順を実行する必要があります。

  1. サブドメインを形成するための適切な顧客固有の DNS ラベルを選択します。
    • ラベルは長さが最大 9 文字で、英字、数字、アンダースコア、ダッシュのみを含めることができます。
    • ワイルドカード サブドメインまたは複数のラベルを持つサブドメインは使用しないでください。
    • たとえば、ラベル contoso を割り当てることができます。

    重要

    完全な顧客サブドメイン (リージョンごとのドメイン名を含む) は、最大 48 文字にする必要があります。 Microsoft Entra ID では、48 文字を超えるドメイン名はサポートされていません。 たとえば、顧客サブドメイン contoso1.1r1.a1b2c3d4e5f6g7h8.commsgw.azure.com は 48 文字です。

  2. この情報を Azure Communications Gateway の番号管理ポータルと Provisioning API で利用可能な「アカウント」構成の一部として使用して Azure Communications Gateway を構成します。
  3. 「顧客テナントにサブドメイン名を登録する」というタイトルの Microsoft Teams ドキュメントに従って、顧客と連絡を取って適切なサブドメインで顧客のテナントを更新します。

顧客テナントを更新するための手配の一環として、管理する DNS サーバー上で、確認コード (顧客がドメイン名でテナントを更新するときに Microsoft 365 から提供される) を含む DNS レコードを作成する必要があります。 これらのレコードにより、Microsoft 365 は顧客テナントがドメイン名の使用を許可されていることを確認できます。 Azure Communications Gateway は、使用する必要がある DNS サーバーを提供します。 顧客から確認コードを取得し、番号管理ポータル (プレビュー) または Provisioning API (プレビュー) を使用して Azure Communications Gateway にアップロードする必要があります。 この手順により、Azure Communications Gateway はドメインを検証する DNS TXT レコードを生成できるようになります。

手順については、「Azure Communications Gateway を使用した Microsoft Teams ダイレクト ルーティングの顧客と番号を管理する」を参照してください。

発信者 ID のスクリーニングのサポート

Microsoft Teams Direct Routing を使用すると、顧客管理者はテナント内のユーザーに任意の電話番号を割り当てることができます。ネットワーク内でその番号を割り当てていない場合でも、それが可能です。 この検証の欠如により、発信者 ID のスプーフィングのリスクが生じます。

発信者 ID のスプーフィングを防ぐために、Azure Communications Gateway は Microsoft Teams から発信されるすべてのダイレクト ルーティング呼び出しをスクリーニングします。 このスクリーニングにより、顧客は、割り当てられた番号からのみ発信することができます。 ただし、番号管理ポータル (プレビュー) および Provisioning API (プレビュー) で利用できる "アカウント" 構成の一部として、顧客ごとにこのスクリーニングを無効にすることができます。

次の図は、顧客に割り当てられている番号からの INVITE の通話フローを示しています。 この場合、その番号に関する Azure Communications Gateway の構成にはカスタム ヘッダー構成も含まれるため、Azure Communications Gateway はコンテンツを含むカスタム ヘッダーを追加します。

通話スクリーニングとカスタム ヘッダー構成によって許可される Microsoft Teams からの発信通話を示す通話フロー。

顧客に割り当てられた番号からの招待を示す呼び出しフロー図。 Azure Communications Gateway は、内部データベースをチェックして、発信番号が顧客に割り当てられているかどうかを判断します。 番号が割り当てられているため、Azure Communications Gateway は呼び出しを許可します。 Azure Communications Gateway の番号構成には、カスタム ヘッダーのコンテンツが含まれています。 Azure Communications Gateway は、オペレーター ネットワークに呼び出しを転送する前に、ヘッダーのコンテンツを X-MS-Operator-Content ヘッダーとして追加します。

Note

カスタム ヘッダーの名前は、Azure Communications Gateway のデプロイの一部として構成する必要があります。 名前はすべてのメッセージで同じです。 この例では、カスタム ヘッダーの名前は X-MS-Operator-Content です。

次の図は、顧客に割り当てられていない番号からの INVITE の通話フローを示しています。 Azure Communications Gateway は、403 で呼び出しを拒否します。

通話のスクリーニングによって拒否された Microsoft Teams からの発信通話を示す通話フロー。

顧客に割り当てられていない番号からの招待を示す呼び出しフロー図。 Azure Communications Gateway は、内部データベースをチェックして、発信番号が顧客に割り当てられているかどうかを判断します。 番号が割り当てられていないため、Azure Communications Gateway は 403 で呼び出しを拒否します。

Microsoft Phone System の顧客テナントの識別

Microsoft Phone System は、メッセージの Contact ヘッダー内のドメインを使用して、各メッセージのテナントを識別します。 Azure Communications Gateway は、Microsoft Phone System に向けてメッセージの Contact ヘッダーを自動的に再書き込みし、顧客ごとの適切なドメインを含めます。 このプロセスにより、コア ネットワークは番号と顧客ごとのテナントをマッピングする必要がなくなります。

ダイレクト ルーティング用に顧客に割り当てられた各番号を使用して Azure Communications Gateway をプロビジョニングする必要があります。 このプロビジョニングは、Azure Communications Gateway の Provisioning API (プレビュー) または番号管理ポータル (プレビュー) を使用します。

次の図は、ダイレクト ルーティングを使用してオペレーター ネットワークから Microsoft Phone System に送信されるメッセージの Contact ヘッダーを Azure Communications Gateway がどうやって書き換えるかを示しています。

Microsoft Teams への受信メッセージでの Contact ヘッダーの顧客固有の書き換えを示す通話フロー。

オペレーター ネットワークから Azure Communications Gateway に送信された +14255550100 に対する招待を示す呼び出しフロー図。 Azure Communications Gateway は、内部データベースを使用して、番号に対応する適切な顧客のサブドメインを見つけて、そのサブドメインで Contact ヘッダーを更新します。 次に、Azure Communications Gateway は、招待を Microsoft Phone System にルーティングします。

SIP 信号

Azure Communications Gateway は、通話を自動的に相互運用して Direct Routing の次の要件をサポートします。

  • Microsoft Phone System の顧客テナントの識別」で説明されているように、Contact ヘッダーを更新してメッセージを正しくルーティングします。
  • SIP over TLS
  • X-MS-SBC ヘッダー (SBC 機能の記述が含まれる)
  • SDP 本文の a= 属性行に関する厳密な規則。
  • 通話転送処理に関する厳密な規則。

これらの機能は、Azure Communications Gateway による Microsoft Teams ダイレクト ルーティングの認定 SBC 仕様への準拠の一部です。

初期ネットワーク設計の一部として、または Azure Communications Gateway のサポート リクエストを送信することで、いつでも相互運用機能を追加できます。 たとえば、以下に対する追加の相互運用構成が必要になる場合があります。

  • 高度な SIP ヘッダーまたは SDP メッセージ操作。
  • 信頼性の高い暫定メッセージのサポート (100rel)。
  • 初期メディアと後期メディアの間の相互運用。
  • インバンド DTMF トーンによる遠隔での相互運用。
  • SIP メッセージ内の他の場所に一意のテナント ID を配置し、ネットワーク内での利用をしやすくする (たとえば、tgrp パラメーター)。

Microsoft Phone System では、通話元 (A-) と通話先 (B-) の電話番号を E.164 形式にする必要があります。 この要件は、SIP 番号と TEL 番号の両方に適用されます。 すべての番号に E.164 形式を使用するようにネットワークを構成することをお勧めします。 ネットワークで番号を E.164 形式に変換できない場合は、オンボーディング チームに問い合わせるか、サポート リクエストを送信して番号変換の要件について検討してください。

ネットワークと Azure Communications Gateway の間の SIP トランクはマルチテナントです。つまり、すべての顧客からのトラフィックが同じトランクを共有します。

RTP メディア と SRTP メディア

Microsoft Phone System では、通常、メディアに SRTP が必要です。 Azure Communications Gateway は RTP と SRTP の両方をサポートし、それらの間で相互運用できます。 Azure Communications Gateway には、ネットワークを Microsoft Phone System と相互運用できるようにするための追加のメディア操作機能が用意されています。

通話のメディア処理

Azure Communications Gateway をデプロイするときに、サポートするコーデックを選択する必要があります。

Microsoft Teams ダイレクト ルーティングでは、コア ネットワークが通話転送中のリングバック トーン (呼び出し音) をサポートする必要があります。 コア ネットワークはコンフォート ノイズもサポートする必要があります。 コア ネットワークがこれらの要件を満たさない場合、Azure Communications Gateway はメディアを通話に挿入できます。

メディア相互運用性オプション

Azure Communications Gateway には、複数のメディア相互運用性オプションが用意されています。 たとえば、次のことが必要になる場合があります。

  • RTCP の変更処理。
  • 帯域幅割り当ての制御。
  • サービス品質の確保を目的とした特定のメディア トラフィックの優先処理。

Azure Communications Gateway で使用できるメディアの相互運用機能の詳細については、サポート リクエストを送信してください。

Microsoft Phone System のメディア バイパスのサポート (プレビュー)

Azure Communications Gateway には、ダイレクト ルーティング メディア バイパスのプレビュー サポートがあります。 ダイレクト ルーティング メディア バイパスを使用すると、常に Microsoft Phone System 経由でメディアを送信する代わりに、一部のシナリオで Azure Communications Gateway と Microsoft Teams クライアント間でメディアを直接フローさせることができます。 Azure Communications Gateway と Microsoft Phone System の両方が Azure 内に配置されているため、メディアは Azure 経由で引き続きフローします。

メディア バイパスのサポート (プレビュー) がデプロイに役立つと思われる場合は、Microsoft の担当者に要件をお問い合わせください。

次のステップ