ロードバランシングを有効にして、CMSクラスタ導入内の既存の会議またはスペースに参加者を追加する

ダウンロード オプション

  • PDF     (963.3 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
  • ePub     (813.4 KB)
    iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
  • Mobi (Kindle)     (485.4 KB)
    Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示
Updated: 2020 年 6 月 22 日
Document ID:215638

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

    はじめに

    このドキュメントでは、ロードバランシングが有効なクラスタ化CMSの導入で既存のCMS会議に参加者を追加する方法について説明します。

    前提条件

    要件

    次の項目に関する知識があることが推奨されます。

    • CMSロードバランシング(Cisco Meeting Server)
    • CUCMアドホック会議(Cisco Unified Communications Manager)

    このドキュメントでは、クラスタ化されたCallbridge(CB)に対してロードバランシングがすでに設定されており、これらのCMSサーバへの直接コール（既存のCMSスペースへの直接コール）に対応していることを前提としています。これは、次の要件がすでに設定されていることを意味します。

    • アドホック会議に使用されるすべてのCMSサーバがCUCM > メディアリソース > 会議ブリッジに追加され、登録されます
    • メディアリソースグループ(MRG)を含むメディアリソースグループリスト(MRGL)が作成されます。このリストにはCMSサーバのみが含まれ、これはMRGLの最初のグループです
    • ルートグループを含むルートリストが作成されます。このリストにはCMSサーバが含まれ、選択された配布アルゴリズムは循環です

    使用するコンポーネント

    このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

    • CMS 2.9.1
    • CUCM 12.5.1

    このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

    既存のCMS会議に参加者を追加する方法

    注：既存のCMS会議に参加者を追加する方法は主に3つあります。APIを使用した参加者の追加、アクティブコントロールを使用した参加者の追加、アクティブコントロールを使用しない参加者の追加です。

    1. APIを使用して参加者を追加する

    このメソッドを使用するには、CallbridgeグループのLoadbalanceOutgoingCallsを有効にする必要があります。

    このメソッドを使用して参加者を追加するには、API POST要求を/calls/<active-call-id>/participants/に対して行う必要があります。POST要求には、このPOST要求の一部であるremotePartyパラメータの値として会議に追加される参加者のparticipantIDを含める必要があります。

    このPOST要求は、追加される参加者に発信コールを行うようにCMSに指示します。Callbridge GroupのLoadbalanceOutgoingCallsが有効で、CMSのロード制限に達している場合、追加される参加者に発信コールを行うための空きCMSサーバをクラスタ内で検出し、2つのサーバ間で分散コールが作成されます。これは、CMS会議に参加者を追加するためにCMMで使用される方法と同じです。

    2.アクティブコントロールによる参加者の追加

    Active Control participant addを使用するには、CMSサーバと参加者を追加するユーザ間で、まずActive Controlをネゴシエートする必要があります。

    CUCMとCMSを接続するSIPトランクに設定されているSIP Trunk ProfileでActive Controlを有効にする必要があります。これを有効にするには、パラメータAllow IX application mediaを有効にし、Standard SIP Profile For TelePresence Conferencingがデフォルトで有効になっていることに注意してください。さらに、CallbridgeグループのLoadbalanceOutgoingCallsを有効にする必要があります。

    アクティブコントロールを介して参加者が既存のCMS会議に追加されると、CMS1は新しい参加者に発信コールを行うように（アクティブ制御メッセージを介して）ユーザから指示されます。CMS1で設定されているロード制限値に達した後、ユーザがアクティブなコントロールを持つ新しい参加者を追加しようとすると、CMS1で次のエラーメッセージが表示されます（CMSバージョン2.9.1まで）。

    add participant "<participant-uri>" request failed: call bridge unavailable

    これは、参加者がアドホック会議に追加される場合と、アクティブ制御によって既存のCMSスペースに追加される場合の両方のユースケースに適用されます。 

    これは悪影響を及ぼす動作であり、不具合CSCvu72374で追跡されています。

    3.アクティブコントロールのない参加者を追加する

    アクティブ制御を使用せずに参加者を追加すると(つまり、SIPプロファイルでAllow IX application mediaが有効になっていない場合)、CUCMはアクションを開始しているユーザと新しい参加者の間でコールを発信します。次に、ユーザが新しい参加者を会議に参加させる準備ができたら、CUCMはCMS1で実行されているアドホック会議に発信コールを発信します。CMS1でロード制限に達すると、参加者を追加できず、CMS1に次のエラーメッセージが表示されます（55はコール番号の例です）。

    call 55: ending; local teardown, system participant limit reached - not connected after 0:00

    このエラーメッセージは、CMSサーバが着信コールを受信し、最大負荷制限に達した後に出力する通常のエラーメッセージです。その後、コール制御サーバ（CUCMまたはVCS）がクラスタ内の他のメンバーへのコールのルーティングを続行します。ただし、アドホック会議の場合、CUCMにはアドホック会議用のルートリストがないため、これは機能せず、不可能です。

    設定

    このドキュメントでは、既存の会議に参加者を追加する3番目の方法(「アクティブな制御を持たない参加者の追加」)を使用するために必要な設定手順について説明します。

    このドキュメントで説明する設定手順の動作は次のとおりです。

    1.ユーザがアドホック会議を作成し、CMS1サーバがそれをホストしている

    2.アドホック会議が確立された後、CMS1は設定された負荷制限(/system/configuration/clusterでAPIを介して設定)に徐々に到達します

    3.ユーザは進行中のアドホック会議に新しい参加者を追加しようとしますが、新しいユーザは会議に接続されません

    注：この設定手順により、アドホック会議をホストしているCMSサーバが負荷制限に達しても、ユーザは既存のCMSアドホック会議に参加者を追加することができ、アクティブな制御不具合が修正されるまで使用できます。そのアドホック会議では、アクティブ制御は無効になります。 

    ステップ1:Trunk1用の新しいSIPトランクセキュリティプロファイルを作成する

    • System > Security >に移動します。 SIP トランク セキュリティ プロファイル
    • [新規追加（Add New）] を選択します。
    • NameをTrunk1 non secure receiving on 5040に設定します。
    • デバイスセキュリティモードを非セキュアに設定します。
    • 着信ポートを5040に設定します。
    • [保存（Save）] を選択します。
    Trunk1 SIPセキュリティプロファイル

    ステップ2:Trunk2用の新しいSIPトランクセキュリティプロファイルの作成

    • System > Securityの順に移動します。 SIP トランク セキュリティ プロファイル
    • [新規追加（Add New）] を選択します。
    • Nameを5041でTrunk2 non secure receivingに設定します。
    • デバイスセキュリティモードを非セキュアに設定します。
    • 着信ポートを5041に設定します。
    • [保存（Save）] を選択します。
    Trunk2 SIPセキュリティプロファイル

    ステップ3:新しいSIP正規化スクリプトの作成 

    • Device > Device settings の順に移動します。 SIP正規化スクリプト
    • [新規追加（Add New）] を選択します。
    • Nameをremove_conference_from_call_info_headerに設定します。
    • コンテンツでは、次のスクリプトを使用します
    M = {}
function M.outbound_INVITE(msg)
    msg:removeHeaderValue("Call-Info", "<urn:x-cisco-remotecc:conference>")
end
return M
    • [保存（Save）] を選択します。

    ステップ4:新しいSIPプロファイルの作成

    • Device > Device settingsの順に移動します。 SIP プロファイル
    • Standard SIP Profile For TelePresence Conferencingを選択し、コピーします
    • NameをNo active control telepresence conferencingに設定します。
    • ページの下部にあるAllow iX Application Mediaチェックボックスのチェックマークを外します
    • [保存（Save）] を選択します。

    ステップ5:新しいパーティションの作成

    • Call routing > Class of Controlの順に移動します。 パーティション
    • [新規追加（Add New）] を選択します。
    • Nameをcms_adhoc_numbersに設定します。
    • [保存（Save）] を選択します。

    ステップ6:新しいコーリングサーチスペース(CSS)を作成します。

    • 移動先 コールルーティング>制御クラス>コーリングサーチスペース
    • [新規追加（Add New）] を選択します。
    • NameをCMS_adhoc_numbersに設定します。
    • 手順5で作成したパーティションcms_adhoc_numbersを追加します。
    • [保存（Save）] を選択します。
    コーリング サーチ スペースの設定

    ステップ7：新しいSIPトランクTrunk1を作成します。

    • [デバイス（Device）] > [トランク（Trunk）] に移動します。
    • [新規追加（Add New）] を選択します。
    • [トランク タイプ（Trunk Type）] で [SIP トランク（SIP Trunk）] を選択します。
    • [次へ（Next）] を選択します。
    • 次の値を入力して保存します。
    Device Name SIPトランクの名前Trunk1を入力します。
    すべてのアクティブなUnified CMノードで実行 オン
    送信先アドレス CUCMサーバのIPを入力します(10.48.36.50など)。
    宛先ポート Trunk2がリッスンするポート(5041)を入力します。
    SIP トランク セキュリティ プロファイル ステップ1「5040でのTrunk1 non secure receiving」で作成したプロファイルを選択します。
    SIP プロファイル ステップ4「No active control telepresence conferencing
    DTMFシグナリング方式 RFC 2833を選択します
    SIP正規化スクリプト
    		 ステップ3「remove_conference_from_call_info_header」で作成したスクリプトを選択します。
    Trunk1 SIP設定

    ステップ8:新しいSIPトランクTrunk2を作成します。

    • [デバイス（Device）] > [トランク（Trunk）] に移動します。
    • [新規追加（Add New）] を選択します。
    • [トランク タイプ（Trunk Type）] で [SIP トランク（SIP Trunk）] を選択します。
    • [次へ（Next）] を選択します。
    • 次の値を入力して保存します。
    Device Name SIPトランクの名前Trunk2を入力します。
    すべてのアクティブなUnified CMノードで実行 オン
    Calling Search Space ステップ6で作成したCSS CMS_adhoc_numbersを選択します。
    送信先アドレス CUCMサーバ自体のIPアドレスまたはFQDNを入力します(10.48.36.50など)。
    宛先ポート Trunk1がリッスンするポート(5040)を入力します。
    SIP トランク セキュリティ プロファイル ステップ2「5041でのTrunk2 non secure receiving」で作成したプロファイルを選択します。
    SIP プロファイル ステップ4「No active control telepresence conferencing
    DTMFシグナリング方式 RFC 2833を選択します
    SIP正規化スクリプト
    		 既存の正規化スクリプトcisco-meeting-server-interop
    Trunk2 SIP設定

    ステップ9:新しいルートパターンの作成

    • Call routing > Route/Huntの順に移動します。 ルート パターン
    • [新規追加（Add New）] を選択します。
    • 設定する から!
    • ルートパーティションを、手順5で作成したパーティションcms_adhoc_numbersに設定します
    • チェックボックスを有効にする
    • コールの分類をオンネットに変更する
    • ゲートウェイ/ルートリストを、すでに設定されているCMSルートリストに設定します（前述の「要件」の項を参照）。
    • [保存（Save）] を選択します。
    ルート パターン
    CMSロードバランシングのルートリスト
    CMSロードバランシングのルートグループ

    ステップ10:CMSアドホック会議ブリッジの設定を変更する

    • メディアリソースに移動します。 会議ブリッジ
    • 最初のCMSサーバを選択します。
    • 変更： ステップ7で作成したSIPトランクをTrunk1に追加します
    • チェックボックスを有効にする SIPトランクの宛先をHTTPSアドレスとして上書き
    • Hostname/IP Addressフィールドで、そのサーバのWebadmin証明書にも存在する必要がある、特定のCMSサーバのCMS Webadmin FQDNを設定します
    • [保存（Save）] を選択します。
    • 他のすべてのCMSサーバについても同じ手順を実行し、すべてのサーバでTrunk1が使用されるように設定します。ただし、Hostname/IP Addressフィールドを特定のCMS FQDNに変更します
    CMS1
    CMS2
    CMS3

    ステップ11:SIPトランクのTrunk1とTrunk2をリセットする

    • [デバイス（Device）] > [トランク（Trunk）] に移動します。
    • Trunk1とTrunk2を選択します。
    • Reset selectedを選択します。
    • 両方がFull serviceを表示するまで待ちます。

    ステップ12:CMSアドホックサーバのリセット

    • [メディアリソース（Media Resources）] > [会議ブリッジ（Conference Bridge）] に移動します。
    • すべてのCMSサーバの選択
    • Reset selectedを選択します。
    • すべてのサーバが登録済みと表示されるまで待ちます。

    確認

    ここでは、設定が正常に機能しているかどうかを確認します。

    • アドホック会議を作成し、会議をホストしているCMSサーバを確認します。
    アドホック会議をホストするCMS1
    • そのCMSサーバの現在のメディア処理の負荷を確認し、API GETを使用して/system/loadにアクセスします。
    現在のメディアロード
    • パラメータloadlimitを使用して/system/configuration/clusterにPOSTを送信して、サーバの負荷制限をメディア処理の負荷よりも低い値に設定します(1000など)。
    ロード制限の変更
    • 会議に新しい参加者を追加します。CMS1が上限に達したため、参加者が追加され、CMS1と別のCMSサーバの間に配布が作成されます
    分散型コール

    トラブルシュート

    現在、この設定に関する特定のトラブルシューティング情報はありません。

    ログ分析には、Collaboration Solutions Analyzerツールを使用できます。

    関連情報

    更新履歴

    改定 発行日 コメント
    1.0
    17-Jun-2020
    初版
    TAC Authored

    シスコ エンジニア提供

    • ナートオマット
      Cisco TACエンジニア
    • 編集：Lidiya Bogdanova
      Cisco TACエンジニア

    このドキュメントは役に立ちましたか?

    Feedbackフィードバック

    シスコに問い合わせ

    このドキュメントは次の製品に対応しています