Azure Communications Gateway をデプロイする

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

[前提条件]

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

次の 2 種類のテストでは、グローバルにルーティング可能な数値を所有する必要があります。

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

割り当てる必要がある数値の数を次の表に示します。

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

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

1. Azure portal にサインインします。

2. ページの上部にある検索バーで、Communications Gateway を検索し、[ Communications Gateways] を選択します。

   

3. [作成] オプションを選択します。

   

4. 「Azure Communications Gateway をデプロイするための基本情報の収集」で収集した情報を使用して、[基本構成] タブのフィールドに入力し、[次へ: サービス リージョン] を選択します。

5. サービス リージョンの構成値の収集 で収集した情報を使用して、[ サービス リージョン] タブのフィールドに入力し、[ 次へ: Communications Services] を選択します。

6. [ Communications Services 構成] タブでサポートする通信サービスを選択し、[ 各通信サービスの構成値の収集 ] で収集した情報を使用してフィールドに入力し、[ 次へ: テスト行] を選択します。

7. 「 サービス検証番号の値を収集 する」で収集した情報を使用して、[ テストライン 構成] タブのフィールドに入力し、[ 次へ: タグ] を選択します。

   • 統合テスト用に数値を構成しないでください。
   • Microsoft Teamsダイレクト ルーティングでは、サービス検証番号は必要ありません。

8. (省略可能)Azure Communications Gateway リソースのタグを構成します。作成する各タグの 名前 と 値 を入力します。

9. [Review + create](レビュー + 作成) を選択します。

構成を正しく入力すると、画面の上部に 検証に合格した メッセージが Azure portal に表示されます。 [ 確認と作成 ] セクションに移動します。

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

Azure Communications Gateway の構成を送信する

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

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

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

リソースがプロビジョニングされるまで待ちます。 リソースの準備ができたら、リソースの概要の [ プロビジョニングの状態] フィールドが [完了] に変わります。定期的にチェックインして、[プロビジョニングの状態] フィールドが [完了] かどうかを確認することをお勧めします。この手順には、最大 2 週間かかる場合があります。

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

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

1. オンボード チームと 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 からダウンロードし、ネットワークにインストールします。
2. Azure Communications Gateway の信頼性に関するページで説明されている通話ルーティング要件を満たすようにインフラストラクチャを構成します。
   • ネットワークによっては、SBC、ソフトスイッチ、アクセス制御リスト (ACL) の構成が必要になる場合があります。

   Important

   SBC、ファイアウォール、ACL を構成する場合は、Azure Communications Gateway で使用される IP アドレスがメンテナンス、スケーリング、または障害シナリオの結果として変更される可能性があるため、オンボード チームが提供する /28 IP 範囲の両方からトラフィックをネットワークが受信できることを確認します。

   • ネットワークは、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 に置き換えます。
3. Azure Communications Gateway に統合 MCP が含まれている場合は、MCP への接続を構成します。
   1. Azure Communications Gateway リソースの [概要 ] ページに移動します。
   2. 各 サービスの場所 セクションで、 MCP ホスト名 フィールドを見つけます。
   3. 次の形式の 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>
      

4. ルーターとピアリング接続を構成して、Azure Communications Gateway へのすべてのトラフィックが Microsoft Azure Peering Service Voice (MAPS Voice とも呼ばれます) または ExpressRoute Microsoft ピアリングを介していることを確認します。
5. オンプレミスのエッジ ルーターで双方向転送検出 (BFD) を有効にして、リンク障害の検出を高速化します。
   • 間隔は 150 ミリ秒 (150 ミリ秒を使用できない場合は 300 ミリ秒) にする必要があります。
   • MAPS Voice では、BFD は各プライベート ネットワーク インターフェイス (PNI) の BGP ピアを起動する必要があります。
6. 通信プラットフォームのその他の要件 (たとえば、オペレーター接続または 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 の概要」を参照してください。

次のステップ