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

重要

このドキュメントで説明されている機能は、現在、パブリック プレビュー段階にあります。 このプレビュー バージョンはサービス レベル アグリーメントなしで提供されています。運用環境のワークロードに使用することはお勧めできません。 特定の機能はサポート対象ではなく、機能が制限されることがあります。 詳しくは、Microsoft Azure プレビューの追加使用条件に関するページをご覧ください。

重要

Dynamics 365 Omnichannel のお客様の場合、Microsoft では、ダイレクト ルーティング関連のすべてのシナリオに対して GA レベルのサポートを提供しています。 Dynamics Omnichanell の音声の詳細については、「音声チャネルの概要」を参照してください。

この記事では、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 ベンダーから提供されている相互接続の手順やドキュメントを参照してください。

注意

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

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

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

既に Office 365 をご利用で、Microsoft 365 Admin Centerでドメインを登録されているお客様は、同じドメインから SBC FQDN を利用できます。 O365 で以前使用していないドメインは、プロビジョニングする必要があります。

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

Note

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

重要

パブリックプレビュー中のみ: Teamsに登録されていないドメインに ワイルドカード証明書を使用する予定がある場合は、サポート チケットを発行してください。チームは、それを信頼されたドメインとして追加します。

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

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

含まれる CA 証明書の一覧

重要

Azure Communication Services ダイレクト ルーティングは、TLS 1.2 (またはそれ以降のバージョン) のみをサポートします。 サービスへの影響を回避するには、SBC が TLS1.2 をサポートするように構成されていて、次のいずれかの暗号スイートを使用して接続できることを確認します。

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)

SBC の ペアリングは、Communication Services のリソース レベルで動作します。 つまり、1つの Communication Services リソースに対して、多くの SBC をペアリングできます。 ただし、1 つの SBC を複数の Communication Services リソースにペアリングすることはできません。 複数の異なるリソースにペアリングするには、重複しない SBC の FQDN が必要です。

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.1 to 52.115.255.254)
  • 52.120.0.0/14 (IP addresses from 52.120.0.1 to 52.123.255.254)

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

SIP シグナリング: Port

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 とポート範囲

メディア トラフィックは、メディア プロセッサと呼ばれる独立したサービスとの間で送受信されます。 Communication Services のメディア プロセッサは発行時に、任意の Azure IP アドレスを使用できます。 アドレスの全一覧をダウンロードしてください。

ポートの範囲

メディア プロセッサのポート範囲を次の表に示します。

トラフィック ソース 終了 送信元ポート 宛先ポート
UDP または SRTP メディア プロセッサ SBC 3478–3481 and 49152–53247 SBC で定義
UDP または SRTP SBC メディア プロセッサ SBC で定義 3478–3481 and 49152–53247

注意

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

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

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

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

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

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

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

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

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

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

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

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

次の手順

概念説明のドキュメント

クイックスタート