Azure Communications Gateway をデプロイする

[アーティクル]
04/29/2024

この記事では、Azure における Azure Communications Gateway リソースの計画と作成について説明します。

前提条件

「Azure Communications Gateway のデプロイの準備をする」を完了します。収集したすべての情報にアクセスできることを、その手順に従って確認します。

重要

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

オペレーター接続または Teams Phone Mobile サービスの場合も、Microsoft とオペレーター接続または Teams Phone Mobile 契約を締結している必要があります。これらのプログラムの詳細については、「オペレーター接続」または「Teams Phone Mobile」を参照してください。

Zoom Phone Cloud Peering の場合は、Zoom でオンボードプロセスを開始して、Zoom Phone Cloud Peering プロバイダーになる必要もあります。 Cloud Peering の詳細については、Zoom のクラウドピアリングの情報を参照してください。

重要

選択した通信サービスのオンボードプロセスと、オンボードプロセスによって導入された依存関係を完全に理解する必要があります。

デプロイおよびオンボードプロセスで時間がかかることを考慮しておいてください。たとえば、新しい Azure Communications Gateway リソースがプロビジョニングされてご自分のネットワークに接続できるようになるまで最長 2 週間かかる場合があります。

次の 2 種類のテストでは、グローバルにルーティング可能な番号を所有している必要があります:

デプロイ時および統合時のスタッフによる統合テスト
選択した通信サービスによるサービス検証 (継続的な通話テスト)

次の表では、割り当てる必要がある番号の数について説明します。

サービス	統合テスト用の番号	サービス検証番号
オペレーター接続	1 (最小)	- 運用環境のデプロイ: 6 - ラボのデプロイ: 3
Teams Phone Mobile	1 (最小)	- 運用環境のデプロイ: 6 - ラボのデプロイ: 3
Microsoft Teams Direct Routing	1 (最小)	なし (該当なし)
Zoom Phone Cloud Peering	1 (最小)	- 米国とカナダ: 6 - その他の地域: 2
Azure Operator 通話保護プレビュー	1 (最小)	なし (該当なし)

重要

サービス検証番号は、デプロイの有効期間を通じて使用できる必要があります。

Azure Communications Gateway リソースを作成する

Azure portal を使用して Azure Communications Gateway リソースを作成します。

Azure portal にサインインします。
ページの上部にある検索バーで、Communications Gateway を検索して [Communications Gateways] を選択します。
[作成] オプションを選択します。
「Azure Communications Gateway のデプロイに関する基本情報を収集する」で収集した情報を使用して、[基本] 構成タブのフィールドに入力し、[次へ: サービスリージョン] を選択します。
「サービスリージョンの構成値を収集する」で収集した情報を使用して、[サービスリージョン] タブのフィールドに入力し、[次へ: Communications Services] を選択します。
サポートする通信サービスを [Communications Services] 構成タブで選択し、「各通信サービスの構成値を収集する」で収集した情報を使用してフィールドに入力し、[次へ: テスト回線] を選択します。
「サービス検証番号の値を収集する」で収集した情報を使用して、[テスト回線] 構成タブのフィールドに入力し、[次へ: タグ] を選択します。
- 統合テスト用の番号を構成しないでください。
- Microsoft Teams ダイレクトルーティングと Azure Operator 通話保護プレビューでは、サービス検証番号は必要ありません。
(省略可能) Azure Communications Gateway リソースのタグを構成する: 作成したい各タグの [名前] と [値] を入力します。
[Review + create](レビュー + 作成) を選択します。

構成を正しく入力していると、Azure portal の画面の最上部に「検証に成功」のメッセージが表示されます。 [確認と作成] セクションに進みます。

構成を正しく入力していないと、Azure portal の構成が無効なセクションにエラー記号が表示されます。そのセクションを選択してエラーメッセージ内の情報を使用して構成を修正してから、[確認と作成] セクションに戻ります。

[連絡先] セクションに情報がないため失敗した検証が表示されている Azure Communications Gateway ポータルのスクリーンショット。

Azure Communications Gateway の構成を送信する

構成を調べて、要件と一致することを確認します。構成が正しい場合は、[作成] を選択します。

リソースがプロビジョニングされると、「デプロイが完了しました」というメッセージが表示されます。 [リソースグループに移動] を選択し、リソースグループに正しい Azure Communications Gateway リソースが含まれていることを確認します。

Note

すぐに通話を行うことはできません。このガイドの残りの手順を完了した後で、リソースがトラフィックを処理する準備ができます。

完了したデプロイの画面をが表示されている Azure Communications Gateway ポータルの作成のスクリーンショット。

プロビジョニングが完了するまで待つ

リソースがプロビジョニングされるまで待ちます。リソースの準備ができると、リソース概要の [プロビジョニング状態] フィールドは "完了" に変化します。[プロビジョニング状態] フィールドが "完了" になっていないかを知るために定期的に確認することをお勧めします。この手順には最長で 2 週間かかる場合があります。

Azure Communications Gateway をネットワークに接続する

リソースがプロビジョニングされたら、Azure Communications Gateway をネットワークに接続できます。

オンボードチームと TLS 証明書情報を交換します。
1. Azure Communications Gateway は、DigiCert Global Root G2 証明書と Baltimore CyberTrust Root 証明書をルート証明機関 (CA) 証明書としてサポートするように事前構成されています。ネットワークが Azure Communications Gateway に提示する証明書で別のルート CA 証明書が使用されている場合は、オンボードチームにこのルート CA 証明書を提供します。
2. Azure Communications Gateway の証明書のルート CA 証明書は、DigiCert グローバルルート G2 証明書です。ネットワークにこのルート証明書がない場合は、https://www.digicert.com/kb/digicert-root-certificates.htm からダウンロードしてネットワークにインストールします。
Azure Communications Gateway の信頼性に関するページで説明されている通話ルーティング要件を満たすようにインフラストラクチャを構成します。
- ネットワークによっては、SBC、ソフトスイッチ、アクセス制御リスト (ACL) の構成が必要になる場合があります。
重要

SBC、ファイアウォール、ACL を構成する場合、ネットワークでオンボードチームから提供される両方の /28 IP 範囲からトラフィックを受信できるようにします。これは、Azure Communications Gateway で使用される IP アドレスが、メンテナンス、スケーリング、または障害シナリオの結果として変更される可能性があるためです。
- Azure Operator 通話保護プレビューを使用している場合は、ネットワーク内のコンポーネント (通常は SBC) が SIPREC セッション記録クライアント (SRC) として機能する必要があります。
- ネットワークは、Azure Communications Gateway のリージョンごとの FQDN に SIP トラフィックを送信する必要があります。これらの FQDN を検索するには:
  1. Azure portal にサインインします。
  2. ページの上部にある検索バーで、Communications Gateway リソースを検索します。
  3. Azure Communications Gateway リソースの [概要] ページに移動します。
  4. 各 [サービスの場所] セクションで、[ホスト名] フィールドを見つけます。セキュリティで保護された接続を確保するには、このホスト名に対する TLS 接続を検証する必要があります。
- _sip._tls.<regional-FQDN-from-portal> を使用して、リージョンごとに SRV 検索を構成することをお勧めします。 <regional-FQDN-from-portal> を、リソースの [概要] ページの [ホスト名] フィールドのリージョンごとの FQDN に置き換えます。

Azure Communications Gateway に統合 MCP が含まれている場合は、MCP への接続を構成します：

Azure Communications Gateway リソースの [概要] ページに移動します。
各 [サービスの場所] セクションで、[MCP ホスト名] フィールドを見つけます。

次の形式の iFC でテスト番号を構成し、<mcp-hostname> をそのサブスクライバーの優先リージョンの MCP ホスト名に置き換えます。

<InitialFilterCriteria>
    <Priority>0</Priority>
    <TriggerPoint>
        <ConditionTypeCNF>0</ConditionTypeCNF>
        <SPT>
            <ConditionNegated>0</ConditionNegated>
            <Group>0</Group>
            <Method>INVITE</Method>
        </SPT>
        <SPT>
            <ConditionNegated>1</ConditionNegated>
            <Group>0</Group>
            <SessionCase>4</SessionCase>
        </SPT>
    </TriggerPoint>
    <ApplicationServer>
        <ServerName>sip:<mcp-hostname>;transport=tcp;service=mcp</ServerName>
        <DefaultHandling>0</DefaultHandling>
    </ApplicationServer>
</InitialFilterCriteria>

Azure Communications Gateway へのすべてのトラフィックが Microsoft Azure Peering Service Voice (MAPS Voice とも呼ばれます) または ExpressRoute Microsoft ピアリングを経由するようにルーターとピアリング接続を構成します。
オンプレミスのエッジルーターで双方向転送検出 (BFD) を有効にして、リンク障害の検出を高速化します。
- 間隔は 150 ミリ秒 (150 ミリ秒を使用できない場合は 300 ミリ秒) にする必要があります。
- MAPS Voice を使う場合、BFD は各プライベートネットワークインターフェイス (PNI) の BGP ピアを起動する必要があります。
通信プラットフォームの他のすべての要件 (たとえば Operator Connect または Teams Phone Mobile のネットワーク接続仕様) を満たします。 Operator Connect または Teams Phone Mobile の仕様へのアクセスが必要な場合は、オンボーディングチームにお問い合わせください。

アップグレード、メンテナンス、リソース正常性のアラートを構成する

Azure Communications Gateway は、Azure Service Health および Azure Resource Health と統合されています。

Azure Service Health のサービス正常性通知を使って、今後のアップグレードとスケジュールされたメンテナンスアクティビティについてお知らせします。
Azure Resource Health では、リソースの正常性に関するパーソナライズされたダッシュボードが提供されるため、リソースの現在および過去の正常性状態を確認できます。

運用チームに対して次のアラートを設定する必要があります。

アップグレードとメンテナンスアクティビティに関する、サービス正常性通知のアラート。
Azure Communications Gateway の正常性の変化に関する、リソースの正常性に関するアラート。

アラートを使うと、運用チームに変更のプロアクティブな通知を送信できます。たとえば、電子メールや SMS 通知を構成できます。アラートの概要については、「Azure Monitor のアラートとは」を参照してください。 Azure Service Health と Azure Resource Health の詳細については、「Azure Service Health とは」と「Resource Health の概要」を参照してください。

次のステップ

Azure Communications Gateway のプロビジョニング API を統合する

次の方法で共有