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 の信頼されたルート証明書プログラム
重要
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)
次のステップ
概念説明のドキュメント
- テレフォニーの概念
- Azure Communication Services での電話番号の種類
- セッション ボーダー コントローラーをペアリングし、音声ルーティングを構成する
- 通話の自動化の概要
- 料金
クイックスタート
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示