Azure 直接ルーティング インフラストラクチャの要件

この記事では、Azure 直接ルーティングのデプロイを計画する際に留意すべきインフラストラクチャ、ライセンス、セッション ボーダー コントローラー (SBC) 接続について詳しく説明します。

インフラストラクチャの要件

Azure 直接ルーティングをデプロイするために必要な、サポートされている SBC のインフラストラクチャ要件、ドメイン、およびその他のネットワーク接続要件を次の表に示します。

インフラストラクチャ要件 必要なもの
セッション ボーダー コントローラー (SBC) サポートされている SBC。 詳細については、サポートされる SBC に関するページを参照してください。
SBC に接続されたテレフォニー トランク SBC に接続された 1 つまたは複数のテレフォニー トランク。 一方のエンドで、SBC は直接ルーティングを介して Azure Communication Service に接続されます。 PBX や Analog Telephony Adapterといた、サードパーティのテレフォニー エンティティに SBC を接続することもできます。 SBC に接続されているすべての公衆交換電話網 (PSTN) 接続オプションが機能します。 (SBC に対する PSTN トランクの構成については、SBC ベンダーまたはトランク プロバイダーにお問い合わせください)。
Azure サブスクリプション Communication Services リソースを作成する場合や、SBC の構成と接続を作成する場合に使用する Azure サブスクリプション。
Communication Services のアクセス トークン 電話をかけるには、voip スコープの有効なアクセス トークンが必要です。 「アクセス トークン」を参照してください。
SBC のパブリック IP アドレス SBC への接続に使用できるパブリック IP アドレス。 SBC の種類によっては NAT を使用できます。
SBC の完全修飾ドメイン名 (FQDN) 詳細については、「 SBC 証明書とドメイン名」を参照してください。
SBC のパブリック DNS エントリ SBC の FQDN をパブリック IP アドレスにマップするパブリック DNS エントリ。
SBC の信頼済みの公開証明書 Azure 直接ルーティングとのすべての通信に使用される SBC の証明書。 詳細については、「 SBC 証明書とドメイン名」を参照してください。
ファイアウォールの IP アドレスとポート (SIP シグナリングとメディア用) SBC は、クラウド内の次のサービスと通信を行います。

SIP プロキシ: シグナリングを処理します
メディア プロセッサ: メディアを処理します

Microsoft Cloud では、この 2 つのサービスに別々の IP アドレスが割り当てられます。この点については、このドキュメントの中で後述します。

SBC の証明書とドメイン名

SBC の証明書は、証明書署名要求 (CSR) によって要求することをお勧めします。 SBC の CSR を生成する具体的な手順については、ご利用の SBC ベンダーから提供されている相互接続の手順やドキュメントを参照してください。

Note

ほとんどの証明機関 (CA) では、秘密キーのサイズを 2048 以上にすることが求められます。 CSR を生成する場合は、これを念頭に置いておきます。

証明書には、共通名 (CN) またはサブジェクトの別名 (SAN) フィールドとして SBC FQDN が必要です。 証明書は、中間プロバイダーではなく証明機関から直接発行してもらう必要があります。

また、Communication Services の直接ルーティングでは、CN や SAN におけるワイルドカードがサポートされています。ワイルドカードは標準の RFC HTTP Over TLS に準拠している必要があります。

既に Office 365 をご利用で、Microsoft 365 Admin Centerでドメインを登録されているお客様は、同じドメインから SBC FQDN を利用できます。

たとえば、*.contoso.com は、SBC FQDN sbc.contoso.com と一致しますが、sbc.test.contoso.com とは一致しません。

Note

Azure Communication Services ダイレクト ルーティングの SBC FQDN は、Teams ダイレクト ルーティングの SBC FQDN と異なっている必要があります。

Communication Services は、「Microsoft の信頼されたルート証明書プログラム」の一部である認証局 (CA) によって署名された証明書のみを信頼します。 SBC 証明書がプログラムの一部である CA によって署名され、証明書の拡張キー使用法 (EKU) 拡張機能にサーバー認証が含まれる必要があります。 詳細情報:

プログラムの要件 - Microsoft の信頼されたルート証明書プログラム

含まれる CA 証明書の一覧

重要

Azure Communication Services ダイレクト ルーティングは、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 の ペアリングは、Communication Services のリソース レベルで動作します。 つまり、1つの Communication Services リソースに対して、多くの SBC をペアリングできます。 ただし、1 つの SBC を複数の Communication Services リソースにペアリングすることはできません。 複数の異なるリソースにペアリングするには、重複しない SBC の FQDN が必要です。

SBC でダイレクト ルーティング接続に対して相互 TLS (MTLS) サポートが有効になっている場合は、Baltimore CyberTrust Root およびダイレクト ルーティング TLS コンテキストの SBC 信頼されたルート ストアに DigiCert Global Root G2 証明書をインストールする必要があります。 (これは、Microsoft サービス証明書がこれら 2 つのルート証明書のいずれかを使用するためです。)これらのルート証明書をダウンロードするには、「Office 365 暗号化チェーン」を参照してください。 詳細については、「Office TLS 証明書の変更」を参照してください

SIP シグナリング: FQDN

次の 3 つの FQDN が、Communication Services の直接ルーティングの接続ポイントとなります。

  • sip.pstnhub.microsoft.com - グローバル FQDN。最初に試す必要があります。 この名前の解決要求を SBC が送信すると、SBC に割り当てられたプライマリ Azure データセンターを指す IP アドレスが Microsoft Azure DNS サーバーから返されます。 この割り当ては、データセンターのパフォーマンス メトリックと SBC との地理的近接性に基づいています。 返される IP アドレスは、プライマリ FQDN に相当します。
  • sip2.pstnhub.microsoft.com - 第 2 の FQDN。優先度が 2 番目のリージョンに地理的にマップされます。
  • sip3.pstnhub.microsoft.com - 第 3 の FQDN。優先度が 3 番目のリージョンに地理的にマップされます。

次の 3 つの 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.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)

これらすべての IP アドレス範囲に対するファイアウォール ポートを開放して、シグナリングを目的にこれらのアドレスとの間の受信トラフィックと送信トラフィックを許可してください。

SIP シグナリング: ポート

Communication Services の 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 の名前解決を試みます。これが 2 番目に割り当てられるデータセンターに解決されます。まれなケースとして、2 つのリージョンのデータセンターが使用できない場合、SBC は最後の FQDN (sip3.pstnhub.microsoft.com) の名前解決を試み、その結果、第 3 のデータセンターの 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

Note

Microsoft では、SBC での同時通話ごとに少なくとも 2 つのポートを推奨しています。

メディアトラフィック: メディア プロセッサの地理的位置

メディア プロセッサは、SIP プロキシと同じデータセンターに配置されます。

  • NOAM (米国中南部、米国西部と米国東部のデータセンター内の 2 つ)
  • ヨーロッパ (西ヨーロッパ、北ヨーロッパ、スウェーデン、フランス中部)
  • アジア (シンガポール データセンター)
  • 日本 (東日本と西日本のデータセンター)
  • オーストラリア (オーストラリア東部と南東部のデータセンター)
  • ラテン アメリカ (ブラジル南部)
  • アフリカ (南アフリカ北部)

メディア トラフィック: コーデック

SBCとクラウド メディア プロセッサの区間

セッション ボーダー コントローラーとクラウド メディア プロセッサの区間の Azure 直接ルーティング インターフェイスでは、次のコーデックを使用できます。

  • SILK、G.711、G.722、G.729

セッション ボーダー コントローラーで、望ましくないコーデックをプランから除外することにより、特定のコーデックの使用を強制することができます。

SDK アプリを呼び出す Communication Services とクラウド メディア プロセッサの区間

クラウド メディア プロセッサと SDK アプリを呼び出す Communication Services の区間では、G.722 が使用されます。 この区間でさらにコーデックを追加する作業が現在進行中です。

サポートされるセッション ボーダー コントローラー (SBC)

次のステップ

概念説明のドキュメント

クイックスタート