Cloud Connector エディション PSTN サイトの計画
Important
Cloud Connector Edition は、Skype for Business Online と共に 2021 年 7 月 31 日に廃止されます。 organizationが Teams にアップグレードされたら、ダイレクト ルーティングを使用してオンプレミスのテレフォニー ネットワークを Teams に接続する方法について説明します。
効率的でコスト効率の高い通話ルーティングを確保するために、Cloud Connector Edition PSTN サイトを計画する方法については、この記事を参照してください。
この記事では、Cloud Connector の PSTN サイトを計画できるように、Cloud Connector Edition と通話ルーティングについて知っておくべきことについて説明します。 PSTN サイトは、クラウド コネクタ アプライアンスの組み合わせであり、同じ場所に展開され、一般的な PSTN ゲートウェイが接続されています。 このトピックでは、Cloud Connector サイト トポロジを設定して、可能な限り最もコスト効率が高く効果的な方法で、サイトに割り当てられているすべてのユーザーの受信と送信の両方のルーティングを Cloud Connector サイトで処理できるようにする方法について説明します。 Cloud Connector と PSTN サイトの利点の詳細については、「Skype for Business クラウド コネクタ エディションの計画」を参照してください。
Cloud Connector PSTN サイトと通話ルーティング
Cloud Connector PSTN サイトは、不必要な長距離および国/地域間の関税を防ぎ、送信緊急通報が適切なトランクに確実にルーティングされるようにするために作成されたトポロジ構築物です。 緊急サービスへの通話を含め、コスト効率が高く効率的な通話のルーティングを確保するには、PSTN サイトと各サイトへのユーザーの割り当て方法を慎重に計画する必要があります。
Cloud Connector の計画の一環として、オフィスとユーザーが配置されている場所と、PSTN トランクが通信事業者から終了する場所について、通信事業者と話をすることが重要です。 通信事業者と連携して緊急通報のルーティング方法を決定し、その情報を使用して Cloud Connector PSTN サイトを定義し、ユーザーを適切なサイトに割り当てる必要があります。 たとえば、PSTN サイトがストレッチされているデータセンターで終了するトランクが、そのサイトのユーザーに割り当てられているすべての番号の受信ルーティングと送信ルーティングの両方を処理するように構成されていることを確認する必要があります。
各クラウド コネクタ アプライアンスは、複数の IP ゲートウェイ、IP PBX、またはセッション ボーダー コントローラー (SBC) に接続できます。 ゲートウェイと PBX は電話回線トランク (PRI または SIP トランク) に接続されているため、Cloud Connector アプライアンスは、着信および発信呼び出しのために PSTN トランクに論理的に接続されます。 Cloud Connector とオンプレミスの PSTN 接続では、トランクと関連付けられている電話番号をローカル通信事業者から取得します。 ビジネスが大企業の場合、特に複数の都市、州、または国/地域にまたがる場合は、複数の運送業者が存在する可能性があります。 通信事業者は電話番号を所有しているため、緊急通報の処理は運送業者が担当します。
Skype for Business Online は、サイト内のすべての Cloud Connector アプライアンスを均等に扱い、同じサイト内の Cloud Connector アプライアンスにローテーションベースで送信呼び出しをルーティングします。 サイト内の各クラウド コネクタは、同じ PSTN トランクのセット (完全にメッシュ) にクロス接続されます。 各ユーザーは Cloud Connector PSTN サイトに関連付けられているため、そのユーザーからの発信通話 (通常または緊急) は、ユーザーが関連付けられている PSTN サイトのいずれかの Cloud Connector アプライアンスに割り当てられます。
Cloud Connector は、接続されている IP ゲートウェイ、IP-PBX、SBC、または直接 PSTN トランクへの静的通話ルーティングを行います。 Cloud Connector では、宛先に基づくトランクへの動的ルーティング (最小限のコスト ルーティング) や配信元 (静的または動的な緊急通話) に基づく動的ルーティングはまだ実行できません。 着信呼び出しは、番号に関連付けられたトランクからのみ発信できるため、問題ありません。 ただし、送信呼び出しは、サイト内の任意の Cloud Connector アプライアンス (および、その Cloud Connector アプライアンスに接続されている PSTN トランク) に移動できます。これにより、不要な長距離通話が発生する可能性があります。 さらに、Cloud Connector PSTN サイトが異なるエリア コードまたは通信事業者を持つデータセンター全体にストレッチされている場合、緊急通報は行われません。
例
次の例では、トランクを PSTN サイトにグループ化する方法と、ユーザーをサイトに割り当てる方法を示します。 Contoso 会社の場合は、次のことを想定します。
次の 4 つのユーザーがあります。
Redmond WA のユーザー A (米国)
ベルビュー WA のユーザー B (アメリカ)
Centralia WA (アメリカ) のユーザー C
ポートランドまたは (アメリカ) のユーザー D
通信事業者 A は、次の電話番号とトランクを提供します。
Redmond (市域コード 425)
ベルビュー (市域コード 425)
Centralia (市域コード 360)
通信事業者 B では、次の電話番号とトランクが提供されます。
- ポートランド (市域コード 503)
Redmond のユーザー A (データ センター A) とベルビューのユーザー B (データ センター B) が隣り合う郊外にあり、同じ市外コード (425) にあるため、通信事業者 A はベルビューのトランクで Redmond のユーザー A から緊急通報を受けることができます。
そのため、次の図に示すように、ユーザー A と B、および Bellevue と Redmond の Cloud Connector トランクは、同じ Cloud Connector PSTN サイトに存在する可能性があります。 あるオフィスのユーザーからの緊急通報は、もう一方のオフィスのトランクにルーティングできます。 ただし、これが機能することを通信事業者にチェックする必要があります。
次の例も考えてみましょう。
Centralia のユーザー C(その番号が運送業者 A によって提供される)は、車で 2 時間の距離にあり、ベルビューおよび Redmond 425 の市域コードの他の通信事業者 A ユーザーとは異なる市域コード (360) にあります。
したがって、通話がキャリア A から発信されている場合でも、Centralia エリア コード 360 の通信事業者の通話ルーティング ソフトウェアは、ベルビュー市区コード 425 のユーザー B から発信された着信緊急通話を拒否する可能性があります。 この場合、通信事業者は、Cloud Connector とそれに関連する Centralia PSTN サイト内のトランクが、距離とエリア コード間の呼び出しを処理できることを確認することが重要です。
ポートランドのユーザー D は、通信事業者 B によって提供される番号とトランクを使用するため、通信事業者 B が通信事業者 A が所有する電話番号から緊急通報を受ける可能性は非常に低いです。そのため、ユーザー D と Cloud Connector アプライアンスとポートランドの関連トランクは、別の PSTN サイトに配置する必要があります。