Cisco ミーティング サーバー 2.5.2。 ビデオ会議録画機能を備えたスケーラブルかつ復元性の高いモードのクラスター

今回は、フェールオーバー クラスター モードで CMS サーバーをセットアップする際の複雑な点をいくつか示して説明します。


Теория一般に、CMS サーバーの導入には次の XNUMX つのタイプがあります。

• 単一結合(単一の組み合わせ)、つまりこれは、必要なサービスがすべて実行されている XNUMX つのサーバーです。 ほとんどの場合、このタイプの展開は、内部クライアント アクセス、および単一サーバーのスケーラビリティと冗長性の制限が重大な問題ではない小規模な環境、または CMS がアドホック サーバーなどの特定の機能のみを実行する状況にのみ適しています。 Cisco UCM に関するカンファレンス。

  おおよその作業スキーム:
  

• シングルスプリット(単一分割) は、外部アクセス用に別のサーバーを追加することで、以前の展開タイプを拡張します。 従来の展開では、これは、外部クライアントがアクセスできる非武装ネットワーク セグメント (DMZ) に CMS サーバーを展開し、内部クライアントが CMS にアクセスできるネットワーク コアに XNUMX つの CMS サーバーを展開することを意味しました。 この特定の展開モデルは現在、いわゆるタイプに置き換えられています。 シングルエッジ、サーバーで構成されます シスコ エクスプレスウェイ、同じファイアウォール バイパス機能の多くを備えているか、今後備えているため、クライアントは専用のエッジ CMS サーバーを追加する必要がありません。

  おおよその作業スキーム:
  

• スケーラブルで復元力がある(スケーラブルでフォールトトレラント) このタイプには各コンポーネントの冗長性が含まれており、障害発生時の冗長性を提供しながら、システムをニーズに応じて最大容量まで拡張できます。 また、シングル エッジの概念を使用して、安全な外部アクセスを提供します。 これが今回のエピソードで取り上げるタイプです。 このタイプのクラスタの展開方法を理解すれば、他のタイプの展開を理解できるだけでなく、潜在的な需要の増加に対応するために CMS サーバーのクラスタを作成する方法も理解できるようになります。

導入に進む前に、いくつかの基本的なことを理解しておく必要があります。

主な CMS ソフトウェア コンポーネント:

• データベース: ダイヤル プラン、ユーザー スペース、ユーザー自体などの一部の構成を組み合わせることができます。 高可用性のためのクラスタリング (シングルマスター) のみをサポートします。
• コール ブリッジ: 通話とマルチメディア プロセスの管理と処理を完全に制御できる、音声およびビデオ会議用のサービス。 高可用性とスケーラビリティのためのクラスタリングをサポートします。
• XMPPサーバー: Cisco ミーティング アプリケーションや WebRTC(あるいはその両方) を使用したクライアントの登録と認証を担当します(リアルタイム通信、または単にブラウザ内での通信）、コンポーネント間のシグナリングも同様です。 高可用性を目的としてのみクラスタ化できます。
• ウェブブリッジ: クライアントに WebRTC へのアクセスを提供します。
• ロードバランサ：シングル スプリット モードで Cisco Meeting App に単一の接続ポイントを提供します。 外部インターフェイスとポートで受信接続をリッスンします。 同様に、ロード バランサーは XMPP サーバーからの受信 TLS 接続を受け入れ、それを通じて外部クライアントからの TCP 接続を切り替えることができます。
  このシナリオでは、これは必要ありません。
• ターンサーバー: ファイアウォール バイパス テクノロジーを提供し、
  CMS をファイアウォールまたは NAT の背後に配置して、Cisco Meeting App または SIP デバイスを使用して外部クライアントに接続します。 このシナリオでは、これは必要ありません。
• Web管理者：特別な Unified CM 会議を含む、管理インターフェイスと API アクセス。

設定モード

他のほとんどのシスコ製品とは異なり、Cisco Meeting Server は、あらゆるタイプの展開に対応する XNUMX つの設定方法をサポートしています。

• コマンドライン(CLI): 初期構成および証明書タスク用の MMP として知られるコマンド ライン インターフェイス。
• ウェブ管理者: 主に CallBridge 関連の設定用、特に単一の非クラスタ化サーバをセットアップする場合。
• REST API: 最も複雑な構成タスクとクラスター化されたデータベース関連タスクに使用されます。

上記に加えて、プロトコルが使用されます SFTP CMS サーバーとの間でファイル (通常はライセンス、証明書、ログ) を転送します。

シスコの導入ガイドでは、クラスタを導入する必要があることが白文と英語で書かれています。 少なくともXNUMXつ データベースのコンテキストにおけるサーバー (ノード)。 なぜなら新しいデータベース マスターを選択するメカニズムは奇数のノードでのみ機能し、一般にデータベース マスターはほとんどの CMS サーバー データベースと接続します。

実際に見てわかるように、XNUMX つのサーバー (ノード) ではまったく十分ではありません。 選択メカニズムはマスターが再起動されるときに機能し、スレーブ サーバーは再起動されたサーバーが起動された後にのみマスターになります。 ただし、XNUMX つのサーバーのクラスターでマスター サーバーが突然停止した場合、スレーブ サーバーはマスターにはならず、スレーブが停止した場合、残りのマスター サーバーがスレーブになります。

しかし、XMPP のコンテキストでは、実際には XNUMX 台のサーバーからなるクラスターを組み立てる必要があります。 たとえば、XMMP がリーダー ステータスにあるサーバの XNUMX つで XMPP サービスを無効にすると、残りのサーバでは XMPP がフォロワー ステータスのままになり、XMPP への CallBridge 接続が切断されます。 CallBridge は、リーダー ステータスの XMPP にのみ接続します。 そして、これは非常に重要です。なぜなら... 電話はXNUMXつもつながりません。

また、同じ導入ガイドでは、XNUMX つの XMPP サーバーを備えたクラスターが示されています。

上記を考慮すると、その理由が明らかになります。フェイルオーバー モードであるため機能するのです。

この例では、XMPP サーバーは XNUMX つのノードすべてに存在します。

XNUMX つのサーバーがすべて稼働していると仮定します。

DNS レコード

サーバーのセットアップを開始する前に、DNS レコードを作成する必要があります А и SRV 種類：

DNS レコードには、example.com と XNUMX つのドメインがあることに注意してください。 confに.example.com。 Example.com は、すべての Cisco Unified Communication Manager サブスクライバが URI として使用できるドメインであり、インフラストラクチャに存在するか、存在する可能性が最も高くなります。 または、example.com は、ユーザーが電子メール アドレスに使用するのと同じドメインに一致します。 または、ラップトップ上の Jabber クライアントに URI がある可能性があります。 [メール保護]. ドメイン confに.example.com は、Cisco Meeting Server ユーザ用に設定されるドメインです。 Cisco Meeting Server のドメインは次のようになります。 confに.example.com であるため、同じ Jabber ユーザの場合、Cisco Meeting Server にログインするには user@ URI を使用する必要があります。confに.example.com。

基本構成

以下に説明するすべての設定は XNUMX つのサーバーに示されていますが、クラスター内の各サーバーで行う必要があります。

QoSの

CMSが生成するので、 への トラフィックは遅延やパケット損失の影響を受けやすいため、ほとんどの場合、サービス品質 (QoS) を構成することをお勧めします。 これを実現するために、CMS は、生成する DSCP (Differentiated Services Code) によるパケットのタグ付けをサポートします。 DSCP ベースのトラフィックの優先順位付けは、インフラストラクチャのネットワーク コンポーネントによるトラフィックの処理方法によって異なりますが、この例では、QoS のベスト プラクティスに基づいた一般的な DSCP の優先順位付けで CMS を構成します。

各サーバーで次のコマンドを入力します。

dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A

したがって、すべてのビデオ トラフィックは AF41 (DSCP 0x22) とマークされ、すべての音声トラフィックは EF (DSCP 0x2E) とマークされ、SIP や XMPP などの他のタイプの低遅延トラフィックは AF31 (DSCP 0x1A) を使用します。

私たちはチェックします：

NTP

ネットワーク タイム プロトコル (NTP) は、通話や会議の正確なタイムスタンプを提供するだけでなく、証明書を検証するためにも重要です。

次のようなコマンドを使用して、NTP サーバーをインフラストラクチャに追加します。

ntp server add <server>

私たちの場合、そのようなサーバーが XNUMX つあるため、XNUMX つのチームが存在することになります。
私たちはチェックします：

そしてサーバーのタイムゾーンを設定します

DNS

次のようなコマンドを使用して、DNS サーバーを CMS に追加します。

dns add forwardzone <domain-name> <server ip>

私たちの場合、そのようなサーバーが XNUMX つあるため、XNUMX つのチームが存在することになります。
私たちはチェックします：

ネットワークインターフェースの構成

次のようなコマンドを使用してインターフェイスを設定します。

ipv4 <interface> add <address>/<prefix length> <gateway>

私たちはチェックします：

サーバー名（ホスト名）

次のようなコマンドを使用してサーバー名を設定します。

hostname <name>

そして再起動します。


これで基本的な設定は完了です。

証明書

ТеорияCisco Meeting Server では、さまざまなコンポーネント間で暗号化された通信が必要となるため、すべての CMS 導入に X.509 証明書が必要になります。 これらは、サービス/サーバーが他のサーバー/サービスによって信頼されていることを確認するのに役立ちます。

各サービスには証明書が必要ですが、サービスごとに個別の証明書を作成すると、混乱や不必要な複雑さが生じる可能性があります。 幸いなことに、証明書の公開鍵と秘密鍵のペアを生成し、それらを複数のサービス間で再利用できます。 この例では、Call Bridge、XMPP サーバー、Web Bridge、および Web Admin に同じ証明書が使用されます。 したがって、クラスター内のサーバーごとに公開証明書キーと秘密証明書キーのペアを作成する必要があります。

ただし、データベース クラスタリングには特別な証明書要件がいくつかあるため、他のサービスの証明書とは異なる独自の証明書が必要です。 CMS は、他のサーバーで使用される証明書と同様のサーバー証明書を使用しますが、データベース接続に使用されるクライアント証明書もあります。 データベース証明書は、認証と暗号化の両方に使用されます。 クライアントがデータベースに接続するためにユーザー名とパスワードを提供する代わりに、サーバーによって信頼されているクライアント証明書が提示されます。 データベース クラスター内の各サーバーは、同じ公開キーと秘密キーのペアを使用します。 これにより、クラスター内のすべてのサーバーが、同じキー ペアを共有する他のサーバーでのみ復号化できる方法でデータを暗号化できます。

冗長性を機能させるには、データベース クラスターは 3 台以上 5 台以下のサーバーで構成され、クラスター メンバー間の最大ラウンドトリップ時間が 200 ミリ秒である必要があります。 この制限は Call Bridge クラスタリングよりも厳しいため、地理的に分散した展開では制限要因となることがよくあります。

CMS のデータベースの役割には、多数の固有の要件があります。 他の役割とは異なり、クライアント証明書とサーバー証明書が必要です。クライアント証明書には、サーバーに提示される特定の CN フィールドがあります。

CMS は、XNUMX つのマスターといくつかの完全に同一のレプリカを持つ postgres データベースを使用します。 プライマリ データベースは一度に XNUMX つだけです (「データベース サーバー」)。 クラスターの残りのメンバーはレプリカまたは「データベース クライアント」です。

データベース クラスターには専用のサーバー証明書とクライアント証明書が必要です。 これらは証明書 (通常は内部のプライベート認証局) によって署名されている必要があります。 データベース クラスタのどのメンバーでもマスターになれるため、データベース サーバーとクライアント証明書のペア (公開キーと秘密キーを含む) をすべてのサーバーにコピーして、クライアントまたはデータベース サーバーの ID を引き継ぐ必要があります。 さらに、クライアント証明書とサーバー証明書を確実に検証できるように、CA ルート証明書をロードする必要があります。

そこで、次のようなコマンドを使用して、データベースを除くすべてのサーバー サービスで使用される証明書のリクエストを作成します (これには別のリクエストが必要になります)。

pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com

CN では、サーバーの一般的な名前を書きます。 たとえば、サーバーのホスト名が server01, server02, server03の場合、CN は次のようになります。 サーバー.example.com

残りの XNUMX つのサーバーでも同じことを行いますが、コマンドに対応する「ホスト名」が含まれる点が異なります。

次のようなコマンドを使用して、データベース サービスで使用される証明書の XNUMX つのリクエストを生成します。

pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com

pki csr dbclusterclient CN:postgres

どこ dbcクラスターサーバー и dbcクラスタークライアント 私たちのリクエストと将来の証明書の名前、 ホスト名1(2)(3) 対応するサーバーの名前。

この手順は XNUMX つのサーバー (!) でのみ実行し、証明書と対応する .key ファイルを他のサーバーにアップロードします。

AD CS でクライアント証明書モードを有効にする

また、各サーバーの証明書を XNUMX つのファイルにマージする必要があります。*NIX の場合:

cat server01.cer server02.cer server03.cer > server.cer

Windows/DOS の場合:

copy server01.cer + server02.cer + server03.cer  server.cer

そして、各サーバーにアップロードします。
1. 「個別」サーバー証明書。
2. ルート証明書 (存在する場合は中間証明書も併せて)。
3. データベース (「サーバー」および「クライアント」) の証明書と、「サーバー」および「クライアント」データベース証明書の要求を作成するときに生成された .key 拡張子を持つファイル。 これらのファイルはすべてのサーバーで同じである必要があります。
4. XNUMX つの「個人」証明書すべてのファイル。

その結果、各サーバー上で次のようなファイル画像が得られるはずです。

データベースクラスター

すべての証明書が CMS サーバーにアップロードされたので、XNUMX つのノード間のデータベース クラスタリングを構成して有効にすることができます。 最初のステップは、データベース クラスターのマスター ノードとして XNUMX 台のサーバーを選択し、それを完全に構成することです。

マスターデータベース

データベース レプリケーションを設定する最初の手順は、データベースに使用する証明書を指定することです。 これは次のようなコマンドを使用して行われます。

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

次に、次のコマンドを使用して、データベース クラスタリングにどのインターフェイスを使用するかを CMS に指示しましょう。

database cluster localnode a

次に、次のコマンドを使用して、メイン サーバー上のクラスター データベースを初期化します。

database cluster initialize

クライアントデータベースノード

コマンドの代わりに同じ手順を実行します。 データベースクラスターの初期化 次のようなコマンドを入力します。

database cluster join <ip address existing master>

ここで、ip address クラスタが初期化された CMS サーバーの既存のマスター IP アドレス (単に「マスター」)。

次のコマンドを使用して、データベース クラスターがすべてのサーバーでどのように動作するかを確認します。

database cluster status

残りの XNUMX 番目のサーバーでも同じことを行います。

その結果、最初のサーバーがマスターで、残りはスレーブであることがわかります。

ウェブ管理サービス

Web 管理者サービスを有効にします。

webadmin listen a 445

ポート 445 は Web クライアントへのユーザー アクセスに使用されるため、ポート 443 が選択されました。

次のようなコマンドを使用して、証明書ファイルを使用して Web Admin サービスを構成します。

webadmin certs <keyfile> <certificatefile> <ca bundle>

そして、次のコマンドを使用して Web Admin を有効にします。

webadmin enable

すべてが正常であれば、Web Admin がネットワークと証明書に対して正しく構成されていることを示す SUCCESS 行が表示されます。 Web ブラウザを使用してサービスの機能を確認し、Web 管理者のアドレスを入力します。例: cms.example.com：445

Call Bridge クラスタ

Call Bridge は、すべての CMS 導入環境に存在する唯一のサービスです。 Call Bridge は主要な会議メカニズムです。 また、Cisco Unified CM などによって、SIP インターフェイスとの間でコールをルーティングできるようにする SIP インターフェイスも提供します。

以下で説明するコマンドは、適切な証明書を使用して各サーバーで実行する必要があります。
だから：

次のようなコマンドを使用して、証明書を Call Bridge サービスに関連付けます。

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

次のコマンドを使用して、CallBridge サービスを必要なインターフェイスにバインドします。

callbridge listen a

そして、次のコマンドを使用してサービスを再起動します。

callbridge restart

Call Bridge の設定が完了したので、Call Bridge クラスタリングを設定できます。 Call Bridge クラスタリングは、データベースや XMPP クラスタリングとは異なります。 Call Bridge クラスタは、制限なく 2 ～ 8 ノードをサポートできます。 冗長性だけでなくロード バランシングも提供するため、インテリジェントな通話分散を使用して Call Bridge サーバ間で会議をアクティブに分散できます。 CMS には、さらなる管理に使用できる追加機能、Call Bridge グループ、および関連機能があります。

Call Bridge クラスタリングは主に Web 管理インターフェイスを通じて設定されます
以下で説明する手順は、クラスター内の各サーバーで実行する必要があります。
このように、

1. Web から [構成] > [クラスター] に移動します。
2 で Call Bridge ID 一意の名前として、サーバ名に対応する callbridge[01,02,03] を入力します。 これらの名前は任意ですが、このクラスターに対して一意である必要があります。 これらはサーバー識別子 [01,02,03] であることを示すため、本質的に説明的です。
3.B クラスタ化された Call Bridge クラスター内のサーバーの Web 管理者 URL を入力します。 CMS[01,02,03].example.com:445、[アドレス]フィールド。 必ずポートを指定してください。 ピア リンク SIP ドメインは空のままにすることができます。
4. 各サーバの CallBridge トラストに証明書を追加します。このファイルには、次のようなコマンドを使用して、最初にこのファイルにマージしたサーバのすべての証明書が含まれています。

callbridge trust cluster <trusted cluster certificate bundle>

そして、次のコマンドを使用してサービスを再起動します。

callbridge restart

その結果、各サーバーで次の画像が得られるはずです。

XMPP クラスター

CMS の XMPP サービスは、CMA WebRTC Web クライアントを含む Cisco Meeting Apps (CMA) のすべての登録と認証を処理するために使用されます。 Call Bridge 自体も認証目的で XMPP クライアントとして機能するため、他のクライアントと同様に設定する必要があります。 XMPP フォールト トレランスは、バージョン 2.1 以降、運用環境でサポートされている機能です。

以下で説明するコマンドは、適切な証明書を使用して各サーバーで実行する必要があります。
だから：

次のようなコマンドを使用して、証明書を XMPP サービスに関連付けます。

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

次に、次のコマンドを使用してリスニング インターフェイスを定義します。

xmpp listen a

XMPP サービスには一意のドメインが必要です。 これはユーザーのログインです。 つまり、ユーザーが CMA アプリを使用して (または WebRTC クライアントを通じて) ログインしようとすると、userID@logindomain と入力します。 この場合、それは userid@ になります。confに.example.com。 なぜ example.com だけではないのでしょうか? この特定の展開では、Jabber ユーザが Unified CM で使用する Unified CM ドメインを example.com として選択したため、CMS ユーザが SIP ドメインを介して CMS との間でコールをルーティングするには、別のドメインが必要でした。

次のようなコマンドを使用して、XMPP ドメインをセットアップします。

xmpp domain <domain>

そして、次のコマンドを使用して XMPP サービスを有効にします。

xmpp enable

XMPP サービスでは、XMPP サービスに登録するときに使用される各 Call Bridge のクレデンシャルを作成する必要があります。 これらの名前は任意です（コール ブリッジ クラスタリング用に設定した一意の名前とは関係ありません）。 この設定はクラスタ データベースに適合しないため、XNUMX つの XMPP サーバに XNUMX つの Call Bridge を追加してから、クラスタ内の他の XMPP サーバにそれらのクレデンシャルを入力する必要があります。 後で、この名前とシークレットを使用して XMPP サービスに登録するように各 Call Bridge を設定します。

次に、01 つの Call Bridge callbridge02、callbridge03、および callbridgeXNUMX を使用して、最初のサーバ上で XMPP サービスを設定する必要があります。 各アカウントにはランダムなパスワードが割り当てられます。 これらは、後で他の Call Bridge サーバに入力され、この XMPP サーバにログインします。 次のコマンドを入力します。

xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03

その結果、次のコマンドで何が起こったかを確認します。

xmpp callbridge list

以下で説明する手順を実行すると、残りのサーバーにもまったく同じ画像が表示されるはずです。

次に、コマンドのみを使用して、残りの XNUMX つのサーバーにまったく同じ設定を追加します。

xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03

たとえば、余分なスペースが入らないように、Secret は非常に慎重に追加します。


結果として、各サーバーには同じ画像が表示されるはずです。

次に、クラスター内のすべてのサーバーで、次のようなコマンドを使用して前に作成した、XNUMX つの証明書すべてを含むファイルをトラスト内に指定します。

xmpp cluster trust <trust bundle>

次のコマンドを使用して、すべてのクラスター サーバーで xmpp クラスター モードを有効にします。

xmpp cluster enable

クラスターの最初のサーバーで、次のコマンドを使用して xmpp クラスターの作成を開始します。

xmpp cluster initialize

他のサーバーでは、次のようなコマンドを使用してクラスターを xmpp に追加します。

xmpp cluster join <ip address head xmpp server>

次のコマンドを使用して、各サーバーで XMPP クラスターの作成が成功したかどうかを確認します。

xmpp status
xmpp cluster status

最初のサーバー:

XNUMX番目のサーバー:

XNUMX 番目のサーバー:

Call Bridge を XMPP に接続する

XMPP クラスタが実行されているので、XMPP クラスタに接続するように Call Bridge サービスを設定する必要があります。 この構成は Web 管理者を通じて行われます。

各サーバーで、[構成] > [全般] に移動し、フィールドで 一意の Call Bridge 名 サーバに対応する一意の Call Bridge 名を書き込みます コールブリッジ[01,02,03]。 Вполе ドメイン conf.example.ru および対応するパスワードをスパイすることができます
クラスター内の任意のサーバーで次のコマンドを実行します。

xmpp callbridge list

「サーバー」フィールドは空のままにしておきます コールブリッジ DNS SRV ルックアップを実行します _xmpp-component._tcp.conf.example.com利用可能な XMPP サーバーを見つけます。 コールブリッジを XMPP に接続するための IP アドレスはサーバーごとに異なる場合があり、レコード要求に返される値によって異なります。 _xmpp-component._tcp.conf.example.com callbridge は、特定の DNS レコードの優先順位設定に依存します。

次に、[ステータス] > [全般] に移動して、Call Bride サービスが XMPP サービスに正常に接続されているかどうかを確認します。

ウェブブリッジ

クラスター内の各サーバーで、次のコマンドを使用して Web Bridge サービスを有効にします。

webbridge listen a:443

次のようなコマンドを使用して、証明書ファイルを使用して Web Bridge サービスを構成します。

webbridge  certs <keyfile> <certificatefile> <ca bundle>

Web ブリッジは HTTPS をサポートします。 「http-redirect」を使用するように構成されている場合は、HTTP を HTTPS にリダイレクトします。
HTTP リダイレクトを有効にするには、次のコマンドを使用します。

webbridge http-redirect enable

Web Bridge が Call Bridge からの接続を信頼できることを Call Bridge に知らせるには、次のコマンドを使用します。

webbridge trust <certfile>

ここで、これはクラスター内の各サーバーからの XNUMX つの証明書すべてを含むファイルです。

このピクチャはクラスター内のすべてのサーバーに存在する必要があります。


次に、「appadmin」ロールを持つユーザーを作成する必要があります。これは、クラスター内の各サーバーを個別に構成するのではなく、クラスター (!) を構成できるようにするために必要です。こうすることで、設定は、それらは一度作られるという事実。


さらにセットアップするには、使用します Postman.

認可については、「認可」セクションで「基本」を選択します。

CMS サーバーにコマンドを正しく送信するには、必要なエンコーディングを設定する必要があります。

コマンドでWebbridgeを指定します。 POST パラメータ付き URL と意味 cms.example.com



ウェブリッジ自体では、ゲスト アクセス、保護されたアクセスなどの必要なパラメータを指定します。

コール ブリッジ グループ

デフォルトでは、CMS は利用可能な会議リソースを常に最も効率的に利用できるわけではありません。

たとえば、参加者が 3 人いる会議の場合、各参加者は 9 つの異なる Call Bridge に接続される可能性があります。 これら XNUMX つの参加者が相互に通信するために、Call Bridge は同じスペース内のすべてのサーバとクライアント間の接続を自動的に確立し、すべてのクライアントが同じサーバ上にあるかのように見えます。 残念ながら、これの欠点は、XNUMX 回の XNUMX 人による会議で XNUMX つのメディア ポートを消費することです。 これは明らかにリソースの非効率な使用です。 さらに、Call Bridge が本当に過負荷になった場合、デフォルトのメカニズムでは、コールの受け入れを継続し、その Call Bridge のすべての加入者に低品質のサービスを提供します。

これらの問題は、Call Bridge グループ機能を使用して解決されます。 この機能は Cisco Meeting Server ソフトウェアのバージョン 2.1 で導入され、WebRTC 参加者を含むインバウンドとアウトバウンドの両方の Cisco Meeting App（CMA）コールのロード バランシングをサポートするように拡張されました。

再接続の問題を解決するために、Call Bridge ごとに XNUMX つの設定可能な負荷制限が導入されました。

負荷制限 — これは、特定の Call Bridge の最大数値負荷です。 各プラットフォームには、CMS96000 の場合は 1000、仮想マシンの場合は vCPU あたり 1.25 GHz など、推奨される負荷制限があります。 さまざまな通話は、参加者の解像度とフレーム レートに応じて、一定量のリソースを消費します。
NewConferenceLoadLimitBasisPoints (デフォルトは 50% の負荷制限) - サーバーの負荷制限を設定します。この制限を超えると、新しい会議は拒否されます。
既存の会議LoadLimitBasisPoints (デフォルトはloadLimitの80%) - 既存の会議への参加者が拒否されるまでのサーバー負荷値。

この機能はコールの分散とロード バランシングを目的として設計されていますが、TURN サーバ、Web Bridge サーバ、レコーダなどの他のグループも Call Bridge グループに割り当てることができるため、最適に使用できるように適切にグループ化することもできます。 これらのオブジェクトのいずれかがコール グループに割り当てられていない場合、それらは特別な優先順位なしですべてのサーバーで使用できるとみなされます。

これらのパラメータはここで設定されます。 cms.example.com:445/api/v1/システム/構成/クラスター

次に、各コールブリッジに、どのコールブリッジ グループに属しているかを示します。

最初のコールブリッジ

XNUMX番目のコールブリッジ

XNUMX番目のコールブリッジ


したがって、Cisco Meeting Server クラスタのリソースをより効率的に使用するように Call Bridige グループを設定しました。

Active Directory からのユーザーのインポート

Web Admin サービスには LDAP 構成セクションがありますが、複雑な構成オプションは提供されておらず、情報はクラスター データベースに保存されないため、構成は Web インターフェイスを介して各サーバーで手動で行うか、 API を使用しており、「XNUMX 回「起きないでください」を繰り返すために、引き続き API 経由でデータを設定します。

URLを使ってアクセスする cms01.example.com:445/api/v1/ldapServers は、次のようなパラメータを指定して、LDAP サーバー オブジェクトを作成します。

• サーバーIP
• ポート番号
• имяпользователя
• пароль
• 安全に

セキュア - ポートに応じて true または false を選択します。389 - セキュアではありません、636 - 保護されています。


LDAP ソース パラメータを Cisco Meeting Server の属性にマッピングします。
LDAP マッピングは、LDAP ディレクトリ内の属性を CMS 内の属性にマップします。 実際の属性:

• jidマッピング
• 名前マッピング
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

属性の説明JID CMS でのユーザーのログイン ID を表します。 これは Microsoft Active Directory LDAP サーバーであるため、CMS JID は LDAP の sAMAccountName にマップされます。これは基本的にユーザーの Active Directory ログイン ID です。 また、sAMAccountName を取得し、その末尾にドメイン conf.pod6.cms.lab を追加することに注意してください。これは、ユーザーが CMS にログインするために使用するログインだからです。

名前マッピング Active Directory の displayName フィールドに含まれる内容をユーザーの CMS 名フィールドと照合します。

coSpaceNameMapping displayName フィールドに基づいて CMS スペース名を作成します。 この属性は、coSpaceUriMapping 属性とともに、各ユーザーのスペースを作成するために必要です。

coSpaceUriMapping ユーザーの個人スペースに関連付けられた URI のユーザー部分を定義します。 一部のドメインはスペースにダイヤルインするように構成できます。 ユーザー部分がこれらのドメインのいずれかのこのフィールドに一致する場合、通話はそのユーザーのスペースに転送されます。

coSpaceSecondaryUriMapping スペースに到達するための XNUMX 番目の URI を定義します。 これを使用すると、coSpaceUriMapping パラメーターで定義された英数字 URI の代わりに、インポートされたユーザーのスペースに呼び出しをルーティングするための数値エイリアスを追加できます。

LDAP サーバーと LDAP マッピングが構成されます。 次に、LDAP ソースを作成してそれらをリンクする必要があります。

URLを使ってアクセスする cms01.example.com:445/api/v1/ldapSource は、次のようなパラメータを指定して、LDAP ソース オブジェクトを作成します。

• マッピング
• ベースDN
• filter

LDAP 構成が完了したので、手動同期操作を実行できます。

これは、各サーバーの Web インターフェイスでクリックして実行します。 今すぐ同期 セクション Active Directory


またはコマンドを使用して API 経由で POST URLを使用してアクセスする cms01.example.com:445/api/v1/ldapSyncs

臨時会議

これは何ですか？従来の概念では、会議とは XNUMX 人の参加者が互いに会話し、参加者の XNUMX 人（Unified CM に登録されたデバイスを使用）が「会議」ボタンを押して他の人に電話をかけ、その第三者と話した後に行われます。 、もう一度「会議」ボタンを押すと、すべての参加者が三者会議に参加します。

アドホック会議と CMS のスケジュールされた会議の違いは、アドホック会議が CMS への単なる SIP 通話ではないことです。 会議の開始者が全員を同じ会議に招待するためにもう一度 [会議] ボタンをクリックすると、Unified CM は CMS への API 呼び出しを行って、すべての通話が転送されるオンザフライ会議を作成する必要があります。 これらすべては参加者が気づかないうちに起こります。

これは、コールを続行するには、Unified CM が API クレデンシャルとサービスの WebAdmin アドレス/ポート、および SIP トランクを CMS サーバに直接設定する必要があることを意味します。

必要に応じて、CUCM は CMS 内にスペースを動的に作成して、各コールが CMS に到達し、スペースを対象とする着信コール ルールと一致できるようにすることができます。

CUCM との統合 記事で説明されているのと同じ方法で構成されています 前 ただし、Cisco UCM では、CMS 用に XNUMX つのトランク、XNUMX つの会議ブリッジを作成し、SIP セキュリティ プロファイルで XNUMX つのサブジェクト名、ルート グループ、ルート リスト、メディア リソース グループ、およびメディア リソース グループ リストを指定し、いくつかのルーティング ルールを追加する必要があります。 Cisco Meeting Server に送信します。

SIP セキュリティ プロファイル:


トランクス:


各トランクは同じように見えます。




会議ブリッジ


各会議ブリッジは同じように見えます。


ルートグループ


ルート一覧


メディアリソースグループ


メディアリソースグループリスト

通話ルール

Unified CM やExpressway などのより高度なコール管理システムとは異なり、CMS は新しいコールの SIP Request-URI フィールドでドメインを検索するだけです。 SIP INVITE が sip 用の場合: [メール保護]CMS は、domain.com のみを考慮します。 CMS は次のルールに従って通話をルーティングする場所を決定します。

1. CMS はまず、SIP ドメインと着信ルールで設定されているドメインを照合しようとします。 これらの通話は、（「ターゲット」）スペースまたは特定のユーザー、内部 IVR、または直接統合された Microsoft Lync/Skype for Business (S4B) の宛先にルーティングできます。
2. 着信ルールに一致するものがない場合、CMS は通話転送テーブルに設定されているドメインとの一致を試みます。 一致した場合、ルールは明示的に通話を拒否するか、通話を転送できます。 このとき、CMS はドメインを書き換える可能性があります。これは、Lync ドメインを呼び出すのに役立つ場合があります。 また、どのフィールドもそれ以上変更されないことを意味する pass throw を選択したり、内部 CMS ダイヤル プランを使用したりすることもできます。 通話転送ルールに一致しない場合、デフォルトでは通話が拒否されます。 CMS では、コールは「転送」されますが、メディアは依然として CMS にバインドされていることに注意してください。これは、コールがシグナリングおよびメディア トラフィック パス内に存在することを意味します。
この場合、転送された通話のみが発信ルールの対象となります。 これらの設定により、通話の送信先、トランク タイプ (新しい Lync 通話か標準 SIP 通話か)、および通話転送ルールで転送が選択されていない場合に実行できる変換が決定されます。

これは、アドホック会議中に起こったことの実際のログです。

スクリーンショットでは表示が悪いので (改善方法がわかりません)、次のようにログを書きます。

Info	127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call create failed to find coSpace -- attempting to retrieve from database

Info	API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Internal G

Info	127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba

Info	call 7: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg bc0be45e-ce8f-411c-be04-594e0220c38e in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"

Info	call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "[email protected]"

Info	call 7: setting up UDT RTP session for DTLS (combined media and control)
Info	conference "001036270012": unencrypted call legs now present

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg db61b242-1c6f-49bd-8339-091f62f5777a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "[email protected]"

Info	call 8: setting up UDT RTP session for DTLS (combined media and control)

Info	call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "[email protected]"

Info	call 9: setting up UDT RTP session for DTLS (combined media and control)
Info	call 8: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 7: compensating for far end not matching payload types
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 9: BFCP (client role) now active
Info	call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info	call 9: BFCP (client role) now active
Info	call 7: ending; remote SIP teardown - connected for 0:13
Info	call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e

Info	participant "[email protected]" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call 9: on hold
Info	call 9: non matching payload types mode 1/0
Info	call 9: answering offer in non matching payload types mode
Info	call 8: on hold
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: ending; remote SIP teardown - connected for 0:12

アドホック会議自体:


着信ルール
CMS で通話を受信できるようにするには、着信通話のパラメーターを構成する必要があります。 LDAP セットアップで見たように、すべてのユーザーはドメイン conf.pod6.cms.lab でインポートされました。 したがって、少なくとも、このドメインへの呼び出しでスペースをターゲットにする必要があります。 また、各 CMS サーバーの完全修飾ドメイン名 (場合によっては IP アドレス) を対象としたすべてのルールを設定する必要もあります。 外部コール制御である Unified CM は、各 CMS サーバ専用の SIP トランクを個別に設定します。 これらの SIP トランクの宛先が IP アドレスであるかサーバーの FQDN であるかによって、IP アドレスまたは FQDN 宛てのコールを受け入れるように CMS を設定する必要があるかどうかが決まります。

最も優先度の高い受信ルールを持つドメインが、すべてのユーザー スペースのドメインとして使用されます。 ユーザーが LDAP 経由で同期すると、CMS は自動的にスペースを作成しますが、それは URI のユーザー部分 (coSpaceUriMapping) (user.space など) のみです。 一部 ドメイン 完全な URI はこのルールに基づいて生成されます。 実際、この時点で Web Bridge にログインすると、Space URI にドメインがないことがわかります。 このルールを最高の優先順位に設定すると、生成されたスペースのドメインが次のように設定されます。 conf。example.com。


発信ルール

ユーザが Unified CM クラスタへのアウトバウンド コールを発信できるようにするには、アウトバウンド ルールを設定する必要があります。 Jabber など、Unified CM に登録されているエンドポイントのドメインは example.com です。 このドメインへのコールは、標準の SIP コールとして Unified CM 呼処理ノードにルーティングされる必要があります。 メイン サーバーは cucm-01.example.com で、追加サーバーは cucm-02.example.com です。

最初のルールは、クラスター サーバー間の呼び出しの最も単純なルーティングを記述します。

フィールド ドメインからのローカル 発信者の SIP-URI 内で、呼び出された人の「@」記号の後に表示される内容を担当します。 空のままにすると、「@」記号の後に、このコールが通過する CUCM の IP アドレスが表示されます。 ドメインを指定すると、「@」記号の後に実際にドメインが続きます。 これはコールバックするために必要です。そうでないと、SIP-URI name@ip-address 経由でコールバックすることができなくなります。

指示されたら電話する ドメインからのローカル


いつ電話するか NOT 示した ドメインからのローカル


Auto パラメーターでは何も機能しないため、発信呼び出しには必ず Encrypted または Unencrypted を明示的に指定してください。

レコーディング

ビデオ会議は録画サーバーによって録画されます。 Recorder は Cisco Meeting Server とまったく同じです。 Recorder にはライセンスのインストールは必要ありません。 録音ライセンスは、CallBridge サービスを実行しているサーバーに必要です。 録音ライセンスが必要であり、Recorder を実行しているサーバではなく、CallBridge コンポーネントに適用する必要があります。 Recorder は Extensible Messaging and Presence Protocol (XMPP) クライアントとして動作するため、CallBridge をホストするサーバ上で XMPP サーバを有効にする必要があります。

なぜならクラスターがあり、クラスター内の XNUMX つのサーバーすべてにライセンスを「拡張」する必要があります。 次に、ライセンス内の個人アカウントで、クラスターに含まれるすべての CMS サーバーのインターフェイスの MAC アドレスを関連付け (追加) します。

これはクラスター内のすべてのサーバー上にあるはずの画像です

一般に、Recorder を配置するにはいくつかのシナリオがありますが、ここではこれに固執します。


Recorder を設定する前に、実際にビデオ会議を録画する場所を準備する必要があります。 実はここ リンク、すべての録画を設定する方法。 重要なポイントと詳細に焦点を当てます。

1. クラスター内の最初のサーバーから証明書をスリップすることをお勧めします。
2. Recorder Trust で間違った証明書が指定されているために、「Recorder unavailable」エラーが発生する可能性があります。
3. 記録に指定した NFS ディレクトリがルート ディレクトリではない場合、書き込みが機能しない可能性があります。

場合によっては、特定のユーザーまたはスペースの会議を自動的に記録する必要があることがあります。

このために、XNUMX つの CallProfile が作成されます。
録音を無効にした状態


そして自動録画機能付き


次に、自動録音機能を備えた CallProfile を目的のスペースに「添付」します。


CMS では、CallProfile が明示的に任意のスペースに関連付けられている場合、この CallProfile はこれらの特定のスペースに関連してのみ機能することが確立されています。 また、CallProfile がどのスペースにもバインドされていない場合、デフォルトでは、CallProfile が明示的にバインドされていないスペースに適用されます。

次回は、組織の内部ネットワークの外部から CMS にアクセスする方法について説明したいと思います。

ソース：

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4 以降。 pdf

出所： habr.com