次の方法で共有

Skype for Business Serverの仲介サーバー コンポーネント

  • [アーティクル]

サポートされているトポロジ、M:N トランク、メディア バイパス、通話受付制御との関係など、Skype for Business Serverの仲介サーバーについて説明します。

エンタープライズ VoIPを展開するには、1 つ以上の仲介サーバーを展開する必要があります。

仲介サーバーは、内部エンタープライズ VoIP インフラストラクチャと公衆交換電話網 (PSTN) ゲートウェイまたはセッション開始プロトコル (SIP) トランクの間のシグナリングを変換します。 展開によっては、これらのポイント間でメディアも変換します。

Skype for Business Server側では、仲介サーバーは 1 つの相互 TLS (MTLS) トランスポート アドレスでリッスンします。 ゲートウェイ側では、仲介サーバーは、トランクに関連付けられているすべての関連するリッスン ポートをリッスンします。 すべての認定ゲートウェイが TLS をサポートしている必要がありますが、TCP を有効にすることもできます。 TLS をサポートしないゲートウェイのために TCP がサポートされています。

環境内に既存の Public Branch Exchange (PBX) がある場合、仲介サーバーは、エンタープライズ VoIP ユーザーと PBX 間の呼び出しを処理します。 PBX が IP-PBX の場合は、PBX と仲介サーバーの間に直接 SIP 接続を作成できます。 PBX が Time Division Multiplex (TDM) PBX の場合は、仲介サーバーと PBX の間に PSTN ゲートウェイも展開する必要があります。

仲介サーバーは、既定でフロントエンド サーバーと併置されます。 仲介サーバーは、スタンドアロン プールに展開することもできます。

仲介サーバーの機能

仲介サーバーのメイン機能は次のとおりです。

  • Skype for Business Server側での SRTP の暗号化と暗号化解除。

  • TCP 上の SIP (TLS がサポートされないゲートウェイ用) の相互 TLS 上の SIP への変換。

  • 仲介サーバーのSkype for Business Serverとゲートウェイ ピア間のメディア ストリームの変換。

  • ネットワーク外部のクライアントから内部 ICE コンポーネントへの接続。これにより、メディアは NAT およびファイアウォールを通過できます。

  • エンタープライズ VoIP clien.t 上のリモート ワーカーからの呼び出しなど、ゲートウェイがサポートしていない通話フローの仲介役として機能する

  • SIP トランキングを含む展開での SIP トランキング サービス プロバイダーとの連携による PSTN のサポートの提供。これにより、PSTN ゲートウェイを使用する必要がなくなります。

次の図は、基本的な PSTN ゲートウェイとエンタープライズ VoIP インフラストラクチャとの通信時に仲介サーバーによって使用されるシグナリングプロトコルとメディア プロトコルを示しています。

仲介サーバーで使用される信号およびメディアのプロトコル

仲介サーバー プロトコルの図。

注意

PSTN ゲートウェイと仲介サーバーの間のネットワークで TCP または RTP/RTCP (SRTP または SRTCP ではなく) を使用している場合は、ネットワークのセキュリティとプライバシーを確保するための対策を講じてお勧めします。

M:N トランク

Skype for Business Serverは、通話ルーティングのためにトランクの定義の柔軟性をサポートします。 トランクは、仲介サーバーとリッスン ポート番号の間の論理的な関連付けであり、ゲートウェイとリッスン ポート番号です。 これは、複数のことを意味します。仲介サーバーは、同じゲートウェイへの複数のトランクを持つことができます。仲介サーバーは、異なるゲートウェイへの複数のトランクを持つことができます。逆に、ゲートウェイは異なる仲介サーバーへの複数のトランクを持つことができます。

トポロジ ビルダーを使用してゲートウェイをSkype for Business トポロジに追加する場合でも、ルート トランクを作成する必要があります。 特定の仲介サーバーで処理できるゲートウェイの数は、ピーク時のサーバーの処理能力によって異なります。 「Skype for Business Server 2015 のサーバー要件」で説明されているように、Skype for Business Serverの最小ハードウェア要件を満たすハードウェアに仲介サーバーを展開する場合、スタンドアロン仲介サーバーは約 1,000 の呼び出しを処理できます。 仲介サーバーはトランスコーディングを実行しますが、ゲートウェイがメディア バイパスをサポートしていない場合でも、複数のゲートウェイの呼び出しをルーティングします。

通話ルートを定義するときは、そのルートに関連付けられているトランクを指定しますが、そのルートに関連付けられている仲介サーバーは指定しません。 代わりに、トポロジ ビルダーを使用してトランクを仲介サーバーに関連付けます。 つまり、ルーティングによって通話に使用するトランクが決まります。その後、そのトランクに関連付けられている仲介サーバーがその呼び出しのシグナリングを送信します。

仲介サーバーはプールとして展開できます。このプールはフロント エンド プールと併置することも、スタンドアロン プールとしてデプロイすることもできます。 仲介サーバーがフロントエンド プールと併置されている場合、プール サイズは最大 12 (レジストラー プール サイズの制限) にすることができます。 これらの機能を組み合わせると、仲介サーバーの信頼性と展開の柔軟性が向上しますが、次のような機能が必要です。

  • PSTN ゲートウェイ。 Skype for Business Server修飾ゲートウェイは DNS 負荷分散を実装する必要があります。これにより、修飾された公衆交換電話網 (PSTN) ゲートウェイが仲介サーバーの 1 つのプールのロード バランサーとして機能し、これによりプール全体で呼び出しを負荷分散できます。

  • セッション ボーダー コントローラー。 SIP トランクの場合には、ピア エンティティはインターネット テレフォニー サービス プロバイダーのセッション ボーダー コントローラー (SBC) です。 仲介サーバー プールから SBC への方向で、SBC はプール内の任意の仲介サーバーから接続を受信できます。 SBC からプールへの方向では、トラフィックはプール内の任意の仲介サーバーに送信できます。 サービス プロバイダーと SBC で DNS 負荷分散がサポートされている場合には、DNS 負荷分散でこれを実現できます。 別の方法として、サービス プロバイダーにプール内のすべての仲介サーバーの IP アドレスを付与し、サービス プロバイダーは、仲介サーバーごとに個別の SIP トランクとして SBC でこれらの IP アドレスをプロビジョニングします。 この場合、サービス プロバイダーのサーバーに対してサービス プロバイダーが負荷分散を処理します。 サービス プロバイダーや SBC によっては、これらの機能をサポートしていないことがあります。 さらに、サービス プロバイダーによってはこの機能に別料金を課すことがあります。 一般的には、SBC への SIP トランクごとに月額料金が発生します。

  • IP-PBX。 仲介サーバー プールから IP-PBX SIP 終端への方向で、IP-PBX はプール内の任意の仲介サーバーから接続を受信できます。 IP-PBX からプールへの方向で、トラフィックはプール内の任意の仲介サーバーに送信できます。 ほとんどのIP-PBXsは DNS 負荷分散をサポートしていないため、IP-PBX からプール内の各仲介サーバーへの個々の直接 SIP 接続を定義することをお勧めします。 トランク グループにトラフィックが分散されることで、IP-PBX により IP-PBX の負荷分散が処理されます。 このトランク グループには IP-PBX での一貫したルーティング ルールがあることが前提とされています。 特定の IP-PBX がこのトランク グループの概念をサポートしているかどうか、および IP-PBX の独自の冗長性とクラスタリング アーキテクチャとどのように交差するかは、仲介サーバー クラスターが IP-PBX と正しく対話できるかどうかを判断する前に決定する必要があります。

仲介サーバー プールには、対話するピア ゲートウェイの一様なビューが必要です。 つまり、プールのすべてのメンバーが、ピア ゲートウェイの同一定義に構成ストアからアクセスし、発信通話のために同様にピア ゲートウェイと対話するということです。 そのため、一部の仲介サーバーが発信呼び出しのために特定のゲートウェイ ピアと通信するようにプールをセグメント化する方法はありません。 このようなセグメント化が必要な場合は、仲介サーバーの別のプールを使用する必要があります。 たとえば、このトピックでこれまでに詳しく説明した、プールと対話するための関連機能が PSTN ゲートウェイ、SIP トランク、または IP-PBX にない場合がこれに当てはまります。

特定の PSTN ゲートウェイ、IP PBX、または SIP トランク ピアは、複数の仲介サーバーまたはトランクにルーティングできます。 仲介サーバーの特定のプールが制御できるゲートウェイの数は、メディア バイパスを使用する呼び出しの数によって異なります。 多数の呼び出しでメディア バイパスを使用する場合、プール内の仲介サーバーは、シグナリング 層の処理のみが必要であるため、さらに多くの呼び出しを処理できます。

通話受付管理と仲介サーバー

通話受付管理 (CAC) は、使用可能な帯域幅に基づいてリアルタイムのセッション確立を管理して、混雑したネットワークでユーザーの QoE が低下するのを防止します。 これをサポートするために、仲介サーバーは、Skype for Business Server側とゲートウェイ側の 2 つの相互作用の帯域幅管理を担当します。 通話受付管理では、通話の終端エンティティが帯域幅の予約を処理します。 仲介サーバーがゲートウェイ側で操作するゲートウェイ ピア (PSTN ゲートウェイ、IP PBX、SBC) は、Skype for Business Server通話受付制御をサポートしていません。 したがって、仲介サーバーは、ゲートウェイ ピアに代わって帯域幅の相互作用を処理する必要があります。 可能な限り、仲介サーバーは事前に帯域幅を予約します。 予約できない場合 (たとえば、ゲートウェイ側の最終的なメディア エンドポイントのローカリティが、ゲートウェイ ピアへの発信通話に対して不明な場合)、帯域幅は通話が開始されたときに予約されます。 この動作によって帯域幅のオーバーサブスクリプションが生じる可能性がありますが、これが誤着信を防ぐ唯一の方法です。

メディア バイパスと帯域幅の予約は同時に使用することはできません。 メディア バイパスを通話で使用する場合、その通話で通話受付管理を実行することはできません。 この場合、その通話で、制限された帯域幅を使用するリンクがかかわっていないことが前提となります。 仲介サーバーを含む特定の呼び出しに通話受付制御を使用する場合、その呼び出しではメディア バイパスを使用できません。

メディア バイパスまたは通話受付制御の詳細については、「Skype for Businessでのメディア バイパスの計画」または「Skype for Business Serverでの通話受付制御の計画」を参照してください。

Enhanced 9-1-1 (E9-1-1) と仲介サーバー

仲介サーバーには拡張機能があり、拡張 9-1-1 (E9-1-1) サービス プロバイダーと正しく対話できます。 仲介サーバーに特別な構成は必要ありません。 E9-1-1 の対話に必要な SIP 拡張機能は、ゲートウェイ ピア (PSTN ゲートウェイ、IP-PBX、またはインターネット テレフォニー サービス プロバイダーの SBC (E9-1-1 サービス プロバイダーを含む) との対話のために仲介サーバーの SIP プロトコルに既定で含まれています。

E9-1-1 サービス プロバイダーへの SIP トランクを既存の仲介サーバー プールで終了できるか、スタンドアロン仲介サーバーを必要とするかは、E9-1-1 SBC が仲介サーバーのプールと対話できるかどうかによって異なります。 詳細については、Skype for Business Serverの M:N トランクに関するページを参照してください。

メディア バイパスと仲介サーバー

メディア バイパスは、管理者が仲介サーバーを経由することなく、ユーザー エンドポイントと公衆交換電話網 (PSTN) ゲートウェイの間を直接流れる通話ルーティングを構成できるようにするSkype for Business Server機能です。 メディア バイパスは、待機時間、不要な変換、パケット損失の可能性、および潜在的な障害点の数を減らすことで、呼び出し品質を向上させます。 仲介サーバーのないリモート サイトが、制限された帯域幅を持つ 1 つ以上の WAN リンクによって中央サイトに接続されている場合、メディア バイパスは、リモート サイトのクライアントからのメディアが、最初に中央サイトの仲介サーバーに WAN リンクを経由せずにローカル ゲートウェイに直接流れられるようにすることで、帯域幅要件を低下させます。メディア処理のこの削減は、仲介サーバーが複数のゲートウェイを制御する機能を補完します。

メディア バイパスと通話受付管理 (CAC) を同時に使用することはできません。 通話にメディア バイパスを使用している場合、その通話に対して CAC は実行されません。 通話に関連するリンクについて、帯域幅に制約のあるリンクがないことを前提としています。

仲介サーバーのトポロジ

Skype for Business Server仲介サーバーは、既定では Standard Edition サーバー、フロントエンド プール、または存続可能ブランチ アプライアンスと併置されます。 フロントエンド プール内のすべての仲介サーバーは、同じように構成する必要があります。

パフォーマンスに問題がある場合は、1 つ以上の仲介サーバーを専用のスタンドアロン プールに展開することをお勧めします。 SIP トランキングを展開する場合は、スタンドアロン プールを強く推奨します。

メディア バイパスと DNS 負荷分散をサポートする修飾された PSTN ゲートウェイに直接 SIP 接続を展開する場合、スタンドアロン仲介サーバー プールは必要ありません。 これは、修飾されたゲートウェイは仲介サーバーのプールへの DNS 負荷分散が可能であり、プール内の任意の仲介サーバーからトラフィックを受信できるためです。

また、次のいずれかの条件が満たされている限り、IP-PBXsを展開するか、インターネット テレフォニー サーバー プロバイダーのセッション ボーダー コントローラー (SBC) に接続するときに、フロントエンド プールに仲介サーバーを併置することをお勧めします。

  • IP-PBX または SBC は、プール内の任意の仲介サーバーからトラフィックを受信するように構成されており、プール内のすべての仲介サーバーにトラフィックを一様にルーティングできます。

  • IP-PBX はメディア バイパスをサポートしていませんが、仲介サーバーをホストしているフロントエンド プールは、メディア バイパスが適用されない呼び出しの音声トランスコーディングを処理できます。

Microsoft Lync Server 2013 計画ツールを使用して、仲介サーバーを併置するフロント エンド プールが負荷を処理できるかどうかを評価できます。 環境がこれらの要件を満たすことができない場合は、スタンドアロンの仲介サーバー プールをデプロイする必要があります。

次の図は、WAN リンクで接続された 2 つのサイトから成る簡単なトポロジを示しています。 仲介サーバーは、サイト 1 のフロント エンド プールに併置されます。 サイト 1 の仲介サーバーは、サイト 1 の PSTN ゲートウェイとサイト 2 のゲートウェイの両方を制御します。 このトポロジでは、サイトおよび地域情報を使用できるようにメディア バイパスがグローバルに有効になっていて、各 PSTN ゲートウェイ (GW1 と GW2) へのトランクはバイパスが有効になっています。

仲介サーバーがサイト 1 にあり、PSTN ゲートウェイがサイト 2 にある、WAN リンクで接続されたサイトの例

仲介サーバー WAN ゲートウェイを使用した音声トポロジ。

次の図は、仲介サーバーがサイト 1 のフロントエンド プールに併置され、サイト 1 の IP-PBX に直接 SIP 接続されている単純なトポロジを示しています。 この図では、仲介サーバーはサイト 2 の PSTN ゲートウェイも制御します。 Skype for Businessユーザーがサイト 1 と 2 の両方に存在すると仮定します。 また、IP-PBX には、IP-PBX によって制御されるメディア エンドポイントに送信される前に、Skype for Business エンドポイントから発信されるすべてのメディアで走査する必要があるメディア プロセッサが関連付けられているとします。 このトポロジでは、サイトおよび地域情報を使用できるようにメディア バイパスがグローバルに有効になっていて、PBX と PSTN ゲートウェイへのトランクはバイパスが有効になっています。

仲介サーバーがサイト 1 にあり、PBX がサイト 2 にある、WAN リンクで接続されたサイトの例

音声トポロジ 仲介サーバー WAN PBX。

このトピックの最後の図は、仲介サーバーがインターネット テレフォニー サービス プロバイダーの SBC に接続されているトポロジを示しています。

仲介サーバーの計画についての考慮事項

このトピックでは、仲介サーバーの展開に必要な計画決定について説明します。

併置またはスタンドアロン仲介サーバー

仲介サーバーは、既定では Standard Edition サーバーまたはセントラル サイトのフロント エンド プール内のフロント エンド サーバーに併置されます。 処理することができる公衆交換電話網 (PSTN) 通話の数およびプール内で必要なコンピューターの数は、以下に応じて異なります。

  • 仲介サーバー プールが制御するゲートウェイ ピアの数

  • それらのゲートウェイを経由する高ボリューム トラフィックの期間

  • メディアが仲介サーバーをバイパスする呼び出しの割合

計画するときは、メディア バイパス用に構成されていない PSTN 通話と A/V 会議のメディア処理要件と、サポートする必要があるビジー時間呼び出しの数のシグナリング操作を処理するために必要な処理を考慮してください。 CPU が不足している場合は、仲介サーバーのスタンドアロン プールを展開する必要があります。および PSTN ゲートウェイ、IP-PBX、および SBC は、1 つのプール内の併置された仲介サーバーと、1 つ以上のスタンドアロン プール内のスタンドアロン仲介サーバーによって制御されるサブセットに分割する必要があります。

以下を含む、仲介サーバーのプールと対話するための正しい機能をサポートしていない PSTN ゲートウェイ、IP-PBX、またはセッション ボーダー コントローラー (SBC) を展開した場合は、1 つの仲介サーバーで構成されるスタンドアロン プールに関連付ける必要があります。

  • プール内の仲介サーバー間でネットワーク層ドメイン ネーム システム (DNS) 負荷分散を実行する (または、プール内のすべての仲介サーバーにトラフィックを均一にルーティングする)

  • プール内の任意の仲介サーバーからのトラフィックを受け入れる

Microsoft Lync Server 2013 計画ツールを使用して、仲介サーバーをフロント エンド プールと併置して負荷を処理できるかどうかを評価できます。 環境がこれらの要件を満たすことができない場合は、スタンドアロンの仲介サーバー プールをデプロイする必要があります。

中央サイトとブランチ サイトに関する考慮事項

中央サイトの仲介サーバーを使用して、ブランチ サイトでIP-PBXsまたは PSTN ゲートウェイの呼び出しをルーティングできます。 ただし、SIP トランクを展開する場合は、各トランクが終了するサイトに仲介サーバーを展開する必要があります。 中央サイトルートで仲介サーバーを使用して、ブランチ サイトで IP-PBX または PSTN ゲートウェイを呼び出しても、メディア バイパスを使用する必要はありません。 ただし、メディア バイパスを有効にできる場合は、有効にすると、メディア パスが信号パスを通過する必要がなくなるため、メディア パスの遅延を低減して、メディアの品質を高めることができます。 メディア バイパスにより、プールの処理負荷も減少します。

注意

メディア バイパスは、すべての PSTN ゲートウェイ、IP-PBX、および SBC と相互運用できるとは限りません。 マイクロソフトでは、認定パートナーの PSTN ゲートウェイと SBC でテストを行い、Cisco IP-PBX でも一定のテストを行いました。 メディア バイパスは、「 Unified Communications Open 相互運用性プログラム - Lync Server」に記載されている製品とバージョンでのみサポートされます。

ブランチ サイトの回復性が必要な場合は、存続可能なブランチ アプライアンス、またはフロント エンド サーバー、仲介サーバー、ゲートウェイの組み合わせをブランチ サイトに展開する必要があります。 (ブランチ サイトの回復性の前提は、プレゼンスと会議がサイトで回復性を持たないことを前提とします)。音声のブランチ サイト計画に関するガイダンスについては、「Skype for Business Serverでのエンタープライズ VoIP回復性の計画」を参照してください。

IP-PBX との対話の場合、IP-PBX で複数の初期ダイアログと RFC 3960 の対話による初期メディア操作が正しくサポートされていない場合は、IP-PBX から Skype for Businessエンドポイントへの着信呼び出しに対するあいさつの最初のいくつかの単語のクリッピングが発生する可能性があります。 中央サイトの仲介サーバーが、ルートがブランチ サイトで終了する IP-PBX の呼び出しをルーティングしている場合、この問題はより深刻になる可能性があります。これは、シグナリングを完了するためにより多くの時間が必要になるためです。 この動作が発生した場合、最初のいくつかの単語のクリッピングを減らす唯一の方法は、ブランチ サイトに仲介サーバーを展開することです。

最後に、中央サイトに TDM PBX がある場合、または IP-PBX で PSTN ゲートウェイが不要な場合は、仲介サーバーと PBX を接続する通話ルートにゲートウェイを展開する必要があります。

注意

スタンドアロン仲介サーバーのメディア パフォーマンスを向上させるには、これらのサーバーのネットワーク アダプターの Receive-side Scaling (RSS) を有効にする必要があります。 RSS は、着信パケットがサーバーの複数のプロセッサによって平行して処理されるのを可能にします。 詳細については、「 Windows Server での受信側スケーリングの機能強化」を参照してください。 RSS を有効にする方法の詳細については、ネットワーク アダプターのドキュメントを参照してください。