Cisco Meeting Server 2.9 から 3.0 以降へのスムーズなアップグレードのためのガイダンス
内容
はじめに
このドキュメントでは、バージョン2.9以前を実行しているCisco Meeting Server(CMS)環境を3.0以降にアップグレードする際の課題と、それらを処理して円滑なアップグレードプロセスを実現する方法について説明します。
削除された機能:XMPPが削除されました（WebRTCに影響します）、トランク/ロードバランサ、webbridge
機能変更：レコーダとストリーマは現在SIPであり、webbridgeはwebbridge3に置き換えられています
このドキュメントでは、アップグレードの前に考慮する必要があるトピックのみを取り上げます。3.Xで利用可能なすべての新機能をカバーしているわけではありません。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- CMSの管理
- CMSのアップグレード
- 証明書の作成と署名
ここに記載したものは、さまざまな文書で概説されています。 機能に関してさらに詳しい説明が必要な場合は、製品のリリースノートを読み、当社のプログラミングガイドと導入ガイドを参照することをお勧めします(CMSのインストールと設定ガイドおよびCMS製品リリースノート)。
使用するコンポーネント
このドキュメントの情報は、Cisco Meeting Serverに基づくものです。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
このドキュメントは、すでにCMS 2.9.x（またはそれ以前）を導入済みの場合のガイダンスとして使用することを目的としています。単一の統合か復元力かに関係なく、またCMS 3.0へのアップグレードを計画している場合に使用します。 このドキュメントの情報は、CMSのすべてのモデルに関連しています。
アップグレードに関する重要な情報
CMSのアップグレードでサポートされている唯一の方法は、段階的アップグレードです。 これを書いている時点で、CMS 3.5はリリースされています。 CMS 2.9を使用している場合は、段階的にアップグレードする必要があります(2.9 —> 3.0 —> 3.1 —> 3.2 —> 3.3 —> 3.4 —> 3.5(アップグレードプロセスはCMS 3.5の時点で変更されています。そのため、リリースノートを注意深く読んでください!!)。
ステップアップグレードを実行せず、異常な動作が発生している場合は、TACからダウングレードと最初からやり直しを依頼されることがあります。
また、CMS 3.4では、スマートライセンスを使用する必要があります。 CMS 3.4以降にアップグレードしても、従来のライセンスは使用できません。 スマートライセンスを設定していない限り、CMS 3.4以降にアップグレードしないでください。
検討事項の概要
次の質問を使用して、自分の状況に関連するセクションに移動します。 それぞれの考慮事項では、このドキュメントで説明されている詳細へのハイパーリンクを示しています。
ライセンス
アップグレードの前に、サーバに十分なPersonal MultiParty(PMP)/Shared MultiParty(SMP)ライセンスがありますか。
3.0では、ユーザがサインインしていなくても、PMPライセンスが割り当てられます。たとえば、LDAPを介して10000ユーザをインポートしたが、100のPMPライセンスしか持っていない場合、3.0にアップグレードするとすぐにコンプライアンスから外れます。 この使用例では、userProfileが設定されているテナントやsystem/profilesを確認して、値trueのhasLicenseを持つuserProfileが設定されているかどうかを確認してください。
APIでuserProfileを確認し、hasLicense=true set（PMPライセンスユーザを意味する）を持っているかどうかを確認する方法については、このセクションで詳しく説明します。
現在のcms.licファイルにPMP/SMPライセンスはありますか？
3.0以降のライセンス動作の変更により、アップグレードを実行する前に十分なPMP/SMPライセンスがあるかどうかを確認する必要があります。これについては、このセクションで詳しく説明します。
Cisco Meeting Manager(CMM)を導入していますか。
ライセンスの処理方法が変更されたため、CMS 3.0にはCMM 3.0が必要です。90日間のレポートで過去90日間のライセンス消費を確認できるので、環境を3.0にアップグレードする前にCMM 2.9を導入することをお勧めします。これについては、このセクションで詳しく説明します。
スマートライセンスはありますか。
ライセンスの処理方法が変更されたため、CMS 3.0にはCMM 3.0が必要です。したがって、CMMを通じてすでにスマートライセンスを使用している場合は、クラスタにPMPライセンスとSMPライセンスが関連付けられていることを確認します。
Webbridge（WebRTCおよびCMAクライアント）
CMS 2.9でWebRTCを使用していますか。
CMS 3.0でWebbridgeが大幅に変更されました。 webbridge2からwebbridge3への移行とWebアプリケーションの使用に関するガイダンスについては、この項で説明します。
ユーザはCMAシッククライアントを使用していますか。
これらのクライアントはXMPPベースであるため、XMPPサーバが削除されているため、アップグレード後はこれらのクライアントを使用できません。これが使用例に当てはまる場合は、このセクションで詳細を参照してください。
WebRTCでチャットを使用しますか。
チャット機能は、3.0でWebアプリから削除されました。CMS 3.2では、チャットは再導入されましたが、永続的ではありません。 この機能の詳細については、このセクションを参照してください。
ユーザはWebRTCからデバイスへのポイントツーポイントコールを実行していますか。
CMS 3.0では、Webアプリケーションユーザは別のデバイスに直接ダイヤルできなくなりました。次に、ミーティングスペースに参加し、同じアクションを実行する参加者をミーティングに追加する権限を持っている必要があります。 この部品の詳細については、このセクションを参照してください。
ユーザはWebRTCから独自のcoSpaceを作成しますか。
3.0では、Webアプリケーションユーザがクライアントから独自のスペースを作成できるようにするには、coSpaceTemplateをAPIで作成し、ユーザに割り当てる必要があります。これは、LDAPインポート中に手動または自動で行うことができます。 CanCreateCoSpacesがUserProfileから削除されます。 この機能の詳細については、このセクションを参照してください。
Web GUIの変更点
Web管理GUIでwebBridge設定を行っていますか。
webBridge設定は3.0ではGUIから削除されるため、APIでwebbridgeを設定し、現在の設定がGUIにあることを書き留めておく必要があります。これにより、APIでwebBridgeProfilesを適宜設定できます。 この変更の詳細については、このセクションを参照してください。
Web管理GUIで外部設定を設定していますか。
CMS 3.1では、外部設定がGUIから削除されました。 CMS 3.0以前のWeb管理GUI（設定 – >一般 – >外部設定）でWebbridge URLまたはIVRを設定している場合、これらはWebページから削除されているため、APIで設定する必要があります。3.1へのアップグレード前の以前の設定はAPIに追加されないため、手動で行う必要があります。 この変更の詳細については、このセクションを参照してください。
レコーダ/ストリーマ
現在、CMSレコーダまたはストリーマを使用していますか。
CMSレコーダとストリーマコンポーネントが、XMPPベースではなくSIPベースになりました。したがって、XMPPを削除する場合は、アップグレード後にこれらの設定を調整する必要があります。この変更の詳細については、このセクションを参照してください。
Cisco Expresswayの考慮事項
Expresswayを使用してWebRTCをプロキシしている場合、Cisco Expresswayの現在のバージョンは何ですか。
CMS 3.0にはExpressway 12.6以降が必要です。 このWebRTCプロキシ機能の詳細については、このセクションを参照してください。
CMSエッジ
現在、ご使用の環境にCMSエッジはありますか？
CMS EdgeはCMS 3.1に再導入され、外部接続のスケーラビリティが向上しています。 この部品の詳細については、このセクションを参照してください。
CMS(Acano)Xシリーズ
現在、ご使用の環境にxシリーズサーバはありますか。
これらのサーバはCMS 3.0にアップグレードできないため、すぐに交換を検討する必要があります（3.0にアップグレードする前に、仮想マシンまたはCMSアプライアンスに移行してください）。これらのサーバに関するサポート終了のお知らせは、このリンクから入手できます。
SIPエッジ
現在、ご使用の環境でSIP Edgeを使用していますか。
Sip Edgeは、CMS 3.0で完全に廃止されました。 SIPコールをCMSに取り込むには、Cisco Expresswayを使用する必要があります。組織のExpresswayの入手方法については、シスコの代理店にお問い合わせください。
詳細情報
ライセンス：アップグレード前にライセンスを確認する
コンプライアンス違反のライセンスステータスは、2.xバージョンから3.0以降にアップグレードする際に最も影響する問題です。このセクションでは、スムーズなアップグレードに必要なPMP/SMPライセンスの数を決定する方法について説明します。
導入環境を3.0にアップグレードする前に、CMM 2.9を導入し、「Licenses」タブの下の90日のレポートを確認して、ライセンスの使用状況が、CMSノードで現在割り当てられているライセンス量より少なくなっていないかどうかを確認します。
従来のライセンス（cms.licファイルはCMSノードにローカルにインストールされる）を使用する場合は、CMSライセンスファイルを調べて、各CMSノード（各callBridgeノードからWinSCPを介してダウンロード）のパーソナルライセンスおよび共有ライセンス（この図では100/100）の数量を確認します。
すでにSmart Licensingを使用している場合、CMSサーバのCisco Software Smartポータルで割り当てられているPMP/SMPライセンスの数を確認します。
90日レポート(Zipファイルの名前はlicense-data.zip)を開き、daily-peaks.csvという名前のファイルを開きます。
Excelで、PMP列をZからAの順にソートして、上位の値を上位に取得し、SMP列に対して同じ処理を実行します。 このファイルに表示される値は、CMSライセンスファイルで使用可能なライセンスの値よりも低いですか。「はい」の場合、問題なく完全に準拠しています。そうでない場合は、図6の説明に従って警告やエラーが作成されます。図は『CMS導入ガイド』のセクション1.7.3に記載されており、セクション1.7.4にも詳細な情報があります。
図に示すように、過去90日間のピーク時には2.1667のSMPライセンスが使用され、PMPライセンスは使用されませんでした。cms.licファイルには、ライセンスのタイプごとに100ユニットと記載されているため、この設定は完全に準拠しています。したがって、この設定をCMS 3.0にアップグレードする場合は、ライセンスに関する問題は発生しません。ただし、セットアップでLDAPを介して10,000人のユーザがインポートされた場合に問題が発生する可能性があります。現時点では100のPMPライセンスしかありませんが、10000を割り当てるため（hasLicenseをTrueに設定したuserProfileを使用）、この場合、3.0にアップグレードするとすぐにコンプライアンス違反になります。詳細については、次のセクションを参照してください。
アップグレード後にPMPライセンスが割り当てられるユーザ数を確認する
CMS 3.0では、hasLicense=trueでuserProfileをインポートして使用するすべてのユーザに、PMPライセンスが自動的に割り当てられます。
APIで、所有しているuserProfileの数を確認し、いずれかに「hasLicense=true」が設定されているかどうかを確認します。 割り当てられている場合は、そのユーザプロファイルが割り当てられている場所を確認する必要があります。
userProfilesは、次のいずれかのレベルで割り当てることができます。
- Ldapソース
- テナント
- システム/プロファイル
割り当てられたuserProfilesの3つの場所すべてにhasLicense=trueがあることを確認します。
1. Ldapソース/テナント
テナントまたはuserProfileを使用するldapSourceごとに、hasLicenseパラメータがTrueに設定されている場合、そのldapSourceでインポートされたユーザにはPMPライセンスが割り当てられます。 テナントがある場合は、テナントIDをクリックしてuserProfileが割り当てられているかどうかを確認し、そのuserProfileが「hasLicense=true」で設定されているかどうかを確認する必要があります。 テナントは存在しないが、userProfileセットが存在する場合は、それをクリックして「hasLicense=true」があるかどうかを確認します。 どちらかの方法に「hasLicense=true」がある場合、「api/v1/users」のGETを実行し、ldapSourceに関連付けられたldapmappingでjidMappingに使用されるドメインをフィルタリングすることで、インポートされたユーザの数を確認できます。
ステップ 1：ldapSourceからマッピングIDを検索します。
ステップ 2：ldapMappingsを検索してjidMappingを見つけます。
ステップ 3：jidMappingで使用されているドメインをapi/v1/usersで検索します。
ステップ 4：各ldapSourceから見つかったユーザを追加します。 これは、LDAPにインポートされたユーザのうち、PMPライセンスが必要なユーザの数です。
2. システム/プロファイル
userProfileがシステム/プロファイルレベルで設定され、そのuserProfileが「hasLicense=true」の場合、サーバのアップグレード時にCMSにインポートされたすべてのユーザにPMPライセンスが割り当てられます。 10,000ユーザをインポートしたがPMPが100しかなかった場合、CMS 3.0にアップグレードする際にコンプライアンス違反になり、コールの開始時に30秒間の画面メッセージと音声プロンプトが表示される可能性があります。
システムレベルのuserProfileが、ユーザがPMPを取得することを示している場合は、api/v1/usersに移動して、合計ユーザ数を確認します。
以前にldapからすべてのユーザをインポートしたことがあっても、リストから特定のサブセットだけをインポートすればよいことに気付いた場合は、ldapSourceでフィルタを作成し、PMPライセンスを割り当てるユーザだけをインポートします。ldapSourceでフィルタを変更し、api/v1/ldapsyncで新しいLDAP同期を実行します。 これにより、目的のユーザだけがインポートされ、この以前のインポートの他のユーザはすべて削除されます。
十分な数のSMPライセンスがありますか。
CMM 90 Day Reportの毎日のピークを見ていた際に、ピークをカバーするのに十分な数のSMPライセンスをすでに保有していますか。 SMPライセンスは、会議のオーナーがPMPライセンスを割り当てられていない場合（coSpaceオーナー、アドホック会議、TMSスケジュール会議など）に使用されます。 意図的にSMPを使用していて、ピーク時間をカバーするのに十分な数があれば、これで問題ありません。SMPの90日間のピークをチェックしていて、これらが消費される理由が不明な場合は、ここでチェックする項目があります。
1. マージに使用するデバイスが、userProfileを通じてCMSでPMPライセンスを割り当てられたユーザに関連付けられていない場合、アドホックコール（CUCMからエスカレーションされる）はSMPライセンスを使用します。 CUCMは、会議をエスカレーションするユーザのGUIDを提供します。 そのGUIDが、PMPライセンスが割り当てられたMeeting ServerインポートLDAPユーザに対応する場合、そのユーザのライセンスが使用されます。
2. coSpaceのオーナーにPMPライセンスが割り当てられていない場合、それらの特定のcoSpaceへのコールはSMPライセンスを使用します。
3. TMSバージョン15.6以降で会議がスケジュールされている場合、会議の所有者はCMSに送信され、そのユーザにPMPライセンスが割り当てられていない場合、その会議はSMPライセンスを使用します。
CMMの設定
CMS 3.0と同様に、CMSが正常に機能するにはCMM 3.0が必要です。 CMSのライセンスはCMMが担当するため、CMSを3.0にアップグレードする予定の場合は、CMMサーバが必要です。 アップグレードの前にライセンスの消費量を確認できるように、CMS 2.9を使用している間にCMM 2.9を導入することをお勧めします。
CMMは、SMPおよびPMPライセンスとcallBridgeライセンスについて、追加されたすべてのcallBridgeを確認します。 クラスタ内のさまざまなデバイスの中で最も高い番号が使用されます。
たとえば、CMS1に20個のPMPライセンスと10個のSMPライセンスがあり、CMS2に40個のPMPライセンスと5個のSMPライセンスがある従来のライセンスの場合、CMMは40個のPMPライセンスと10個のSMPライセンスがあることをレポートします。
インポートされたユーザよりも多くのPMPライセンスがある場合、PMP（またはSMP）ライセンスに関連する問題はありませんが、その90日間のピークを確認し、使用可能な期間を超えていることが判明した場合でも、CMS 3.0にアップグレードして、CMMで90日間のトライアルライセンスを使用してライセンスの内容を整理するか、アップグレード前に措置を講じることができます。
Webbridgeの設定（WebRTCおよびCMAクライアント）
CMS 3.0ではXMPPサーバコンポーネントが削除され、これによりwebBridgeとCMAシッククライアントを使用する機能が削除されます。 WebBridge3は、ブラウザを使用してWebアプリケーションユーザ（以前のWebRTCユーザ）を会議に接続するために使用されます。 3.0にアップグレードする場合は、webbridge3を設定する必要があります。
このビデオでは、webbridge 3証明書を作成するプロセスについて説明します。
https://video.cisco.com/detail/video/6232772471001?autoStart=true&q=cms
3.0にアップグレードする前に、Webbridge3の設定方法を計画する必要があります。ここでは、最も重要な手順を重点的に説明します。
1. webbridge3用のキーと証明書チェーンが必要です。 古いwebbridge証明書は、証明書にwebbridge3を実行しているサブジェクト代替名(SAN)/共通名(CN)として、すべてのCMSサーバのFQDNまたはIPアドレスが含まれており、次のいずれかを満たしている場合に使用できます。
a.証明書に拡張キー使用法(EKU)がありません（つまり、証明書はクライアントまたはサーバとして使用できます）。
b.証明書にクライアント認証とサーバ認証の両方が含まれている。 HTTP証明書では実際にはサーバ認証のみが必要ですが、C2W証明書ではサーバとクライアントの両方が必要です)。
- 「webbridge3 https」証明書用の新しい証明書を作成する場合は、公開署名することを推奨します（Webアプリケーションの使用時にクライアントで証明書の警告が表示されないようにするため）。 「webbridge3 c2w cert」にも同じ証明書を使用でき、この証明書にはSAN/CN内のwebbridgeサーバのFQDNが必要です。
- CallBridgeは、webbridge3 c2w listenコマンドで設定されたポートを使用して、新しいwebbridge3と通信する必要があります。これは、449など、使用可能な任意のポートにすることができます。ユーザは、callbridgeがこのポートでwebbridge3と通信できることを確認し、必要に応じてファイアウォールの変更を事前に行う必要があります。 「webbridge https」がリッスンに使用するポートと同じにすることはできません。
CMSを3.0にアップグレードする前に、「backup snapshot <servername_date>」を使用してバックアップを取り、callbridgeノードのwebadminページにログインして、すべてのXMPP設定とWebbridge設定を削除することをお勧めします。 次に、サーバのMMPに接続し、SSH接続経由でxmppとwebbridgeを持つすべてのコアサーバで次の手順を実行します。
- xmppの無効化
- xmppリセット
- xmpp証明書なし
- xmppドメインなし
- webbridgeの無効化
- webbridgeリッスンなし
- webbridge証明書なし
- webbridge信頼なし
3.0にアップグレードしたら、以前webbridgeを実行していたすべてのサーバでwebbridge3を設定することから始めます。 これらのサーバを指すDNSレコードがすでに存在するため、これを行う必要があります。このようにすれば、ユーザがwebbridge3に送信された場合、要求を処理する準備が確実に整います。
Webbridge3の設定（すべてのSSH接続）
ステップ 1：webbridge3 httpリスニングポートを設定します。
Webbridge3 httpsリッスンa:443
ステップ 2：ブラウザ接続用のwebbridge3の証明書を設定します。 これはブラウザに送信される証明書であり、ブラウザが接続を信頼するために、パブリックな認証局(CA)によって署名され、ブラウザで使用されるFQDNを含む必要があります。
Webbridge3 https certs wb3.key wb3trust.cer（これは信頼チェーンである必要があります。つまり、エンドエンティティを先頭に、中間CAが続く信頼証明書を順に作成し、RootCAで終了します）。
ステップ 3：callBridgeからwebbridge(c2w)への接続をリッスンするために使用するポートを設定します。 webbridge3 httpsリスニングポートには443が使用されているため、この設定は、たとえば449のような別の使用可能なポートにする必要があります。
Webbridge3 c2wリスニングa:449
4. c2w信頼のためにwebbridgeがcallbridgeに送信する証明書を設定する
Webbridge3 c2w証明書wb3.key wb3trust.cer
5. WB3がcallBridge証明書を信頼するために使用する信頼ストアを設定します。 これは、callbridge CAバンドルで使用される証明書と同じである必要があります（また、先頭に中間証明書、末尾にルートCA、その後にシングルキャリッジリターンが続くバンドルであることが必要です）。
Webbridge3 c2w信頼rootca.cer
6. webbridge3を有効にします
Webbridge3の有効化
CallBridge設定の変更（SSH接続経由）
ステップ 1：webbridge3 c2w証明書に署名したCA証明書/バンドルを使用してcallBridge信頼を設定します。
Callbridge trust c2w rootca.cer（オプション）
ステップ 2：callBridgeを再起動して、新しい信頼を有効にします。 これにより、この特定のcallBridgeのすべてのコールがドロップされるため、注意して使用してください。
Callbridgeの再起動
webBridge3に接続するためのcallBridgeのAPI設定
1. APIでPOSTを使用して新しいwebBridgeオブジェクトを作成し、webbridge c2wインターフェイスホワイトリスト（webbridge3設定のステップ3）で設定されたFQDNとポートを使用してURL値を指定します
c2w://webbridge.darmckin.local:449
この時点で、Webbridge3が再び機能し、スペースをゲストとして参加させることができます。また、以前にユーザをインポートした場合は、ユーザがサインインできる必要があります。
Webアプリユーザー空間の作成権限
WebRTCで独自のスペースを作成することに慣れているユーザはいますか。 CMS 3.0の時点で、Webアプリケーションユーザは、これを許可するcospaceテンプレートが割り当てられていない限り、独自のcoSpaceを作成できません。
coSpaceTemplateが割り当てられている場合でも、他のユーザがダイヤルインできるスペース（URI、コールID、パスコードなし）は作成されません。ただし、coSpaceに「addParticipantAllowed」を含むcallLegProfileがある場合、そのユーザはスペースからダイヤルアウトできます。
新しいスペースにコールするために使用できるダイヤル文字列を設定するには、coSpaceTemplateにaccessMethodTemplate設定が必要です(2.9リリースノート – https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Release_Notes/Version-2-9/Cisco-Meeting-Server-Release-Notes-2-9-6.pdfを参照)。
APIで、coSpaceTemplate(s)を作成してからaccessMethodTemplate(s)を作成し、coSpaceTemplateをldapUserCoSpaceTemplateSourcesに割り当てるか、api/v1/usersでcoSpaceTemplateをユーザに手動で割り当てることができます。
複数のCoSpaceTemplatesとaccessMethodsTemplatesを作成して割り当てることができます。 詳細については、CMS APIガイド(https://www.cisco.com/c/en/us/support/conferencing/meeting-server/products-programming-reference-guides-list.html)を参照してください。
CoSpaceTemplate（API設定）
Name:coSpaceTemplateに付ける任意の名前。
説明：必要に応じて簡単な説明。
callProfile：白色のcallProfileこのテンプレートで作成したスペースを使用しますか？指定されていない場合は、システム/プロファイルレベルで設定されている内容が使用されます。
calllegProfile：このテンプレートで作成されたスペースで使用するcalllegProfileはどれか？ 指定されていない場合は、システム/プロファイルレベルで設定されている内容が使用されます。
dialInSecurityProfile：このテンプレートで作成されたスペースで使用するdialInSecurityProfileはどれか？指定されていない場合は、システム/プロファイルレベルで設定されている内容が使用されます。
AccessMethodTemplate （API構成）
Name:coSpaceTemplateに付ける任意の名前。
uriGenerator：このアクセスメソッドテンプレートのURI値を生成するために使用する式。使用できる文字のセットは'a'から'z'、'A'から'Z'、'0'から'9'、'.'、'-'、'_'、および'$'です。空でない場合は、1文字の'$'である必要があります。 たとえば、$.spaceでは、ユーザーがスペースを作成するときに指定した名前を使用し、「.space」を追加します。「Team Meeting」と入力すると、URL「Team.Meeting.space@domain」が作成されます。
callLegProfile：このテンプレートで作成されたaccessMethodsで使用するcalllegProfileはどれか？ 指定されていない場合は、CoSpaceTemplateレベルに設定されている値が使用され、設定されていない場合は、システム/プロファイルレベルの値が使用されます。
generateUniqueCallId：コスペースのグローバルIDをオーバーライドする、このアクセスメソッドの一意の数値IDを生成するかどうか。
dialInSecurityProfile：このテンプレートで作成されたアクセスメソッドで使用するdialInSecurityProfileはどれか？指定されていない場合は、CoSpaceTemplateレベルに設定されている値が使用され、設定されていない場合は、システム/プロファイルレベルの値が使用されます。
チャット機能
CMS 3.0では常設チャット機能が削除されましたが、CMS 3.2ではスペース内の非常設チャットが返されました。 チャットはWebアプリケーションユーザが利用でき、どこにも保存されません。 CMS 3.2がインストールされると、Webアプリケーションユーザはデフォルトで会議中に互いにメッセージを送信できるようになります。 これらのメッセージは会議中のみ使用可能で、参加後に交換されるメッセージのみが表示されます。遅れて参加したり、スクロールして戻って前のメッセージを表示したりすることはできません。
WebRTCポイントツーポイントコール
CMS 2.9.xでは、WebRTCの参加者はクライアントから他の連絡先に直接ダイヤルできました。 CMS 3.0以降では、これは不可能です。これで、ユーザはスペースにサインインして参加する必要があります。そこから、callLegProfileに権限がある場合(addParticipantsパラメータをTrueに設定)、他の連絡先を追加できます。 これにより、CMSは参加者にダイヤルアウトし、CMSのスペースで会議を行います。
WebBridge設定の主な変更点
CMS 3.0および3.1では、GUIからwebbridge設定の一部が削除または再配置されています。ユーザに一貫したエクスペリエンスを提供するには、これらの設定をAPIで設定する必要があります。 3.xでは、api/v1/webBridgesおよびapi/v1/webBridgeProfilesを使用します。
現在の設定内容を確認して、3.0にアップグレードするときに、それに応じてAPIでwebbridgeおよびwebbridgeプロファイルを設定できるようにします。
3.0では、GUIでWebブリッジの設定が削除され、CMS 3.1では外部アクセスフィールドも削除されました。
GUIでのWebブリッジの設定
- ゲストアカウントクライアントURI：これはwebBridgeを見つけるためにcallBridgeによって使用されました。 WebRTCの展開に複数のwebBridgeが存在する場合、このフィールドはブランクである必要があり、callBridgeが接続する必要がある各webBridgeのapi/v1/webbridgesに一意のURLが必要です。 このフィールドの内容をすべて削除し、APIでwebBridgeが設定されていることを確認します。
- ゲストアカウントJidドメイン：これはCMS 3.0では使用されなくなったため、削除できます。
- IDとパスコードによるゲストアクセス:CMS 3.0で削除され、置き換えられませんでした。
- ハイパーリンク経由のゲストアクセス:「AllowSecrets」設定でAPIのwebBridgeProfilesの下で設定可能になりました。
CMS 3.0では、api/v1/webBridgesから複数のフィールドが削除されています。
- resourceArchive:webbridgeProfilesに追加されました。
- idEntryMode：現在推奨されていません。
- allowWeblinkAccess:allowSecretsとしてwebBridgeProfilesに追加されました。
- showSignin:webBridgeProfiles内でuserPortalEnabledになりました。
- resolveCoSpaceCallIds:webbridgeProfilesに追加されました。
- resolveLyncConferenceIDs:webbridgeProfilesに追加されました。
WebBridgeプロファイル
- resourceArchive：カスタム背景を使用し、リソースアーカイブがWebサーバに保存されている場合は、ここにURLを入力します。
- allowPasscodes:falseの場合、ユーザはゲストとして会議に参加できません。 サインインするか、スペース情報とシークレットを含むURLのみを使用できます
- allowSecrets：これがfalseに設定されている場合、ユーザはhttps://meet.company.com/meeting/040478?secret=gPDnucF8is4W1cS87_l.zwなどのURLを使用してスペースに参加できません。ユーザはhttps://meet.company.comを使用し、コールID/会議ID/URIとPIN/パスコード（設定されている場合）を入力する必要があります。
- userPortalEnabled：これがfalseに設定されている場合、Webアプリポータルのランディングページにサインインオプションが表示されません。コールID/会議ID/URIとPIN/パスコードを入力するためのフィールドが表示されるだけです（設定されている場合）。
- allowUnauthenticatedGuests:Falseに設定すると、ゲストは、会議IDとシークレットを含む完全なURLを使用していても会議に参加できません。 Falseの場合、サインインできるユーザーのみが会議に参加できます。 例： ユーザ2がユーザ1の会議のURLを使用しようとしています。 URLを入力した後、User2はUser1の会議を続行するためにサインインする必要があります。
- resolveCoSpaceCallIds:Falseに設定した場合、ゲストはURIとPIN/パスコード（使用している場合）を入力しないと会議に参加できません。 コールID/会議ID/数値IDは受け付けられません。
- resolveCoSpaceUris:off、domainSuggestionDisabled、およびdomainSuggestionEnabledの3つの設定が可能です。このWebBridgeが、ビジターのcospaceミーティングへの参加を許可する目的で、coSpaceおよびcoSpace accessMethod SIP URIを受け入れるかどうか。
- 'off'に設定すると、URIによる参加が無効になります。
- 「domainSuggestionDisabled」に設定されている場合、URIによる参加が有効になっていますが、このwebBridgeProfileを使用するwebBridgeではURIのドメインが自動完了または確認されません。
- 「domainSuggestionEnabled」に設定すると、URIによる参加が有効になり、このwebBridgeProfileを使用してURIのドメインをwebBridgeで自動補完および検証できます。
外部アクセスセクションをWeb GUIから削除
CMS 3.1では、外部アクセスセクションがWeb GUIから削除されました。アップグレード前にこれらの設定が行われていた場合は、APIのwebbridgeProfilesで再設定する必要があります。
最初に、前のセクションの説明に従ってwebbridgeProfileを作成する必要があります。webbridgeProfileを作成したら、新しく作成したwebBridgeProfileの下にあるAPIで使用可能なリンクを使用して、IVR番号やWeb Bridge URIを作成できます。
webBridgeProfileごとに最大32のIVR番号または32のwebbridgeAddressesを作成できます
録画またはストリーミング
CMS 2.9.x以前のレコーダおよびストリーマコンポーネントはXMPPクライアントで、CMS 3.0からはSIPベースです。 これにより、APIのデフォルトのレイアウトを使用して、録音やストリーミングのレイアウトを変更できるようになりました。また、録音/ストリーミングセッションに名前のラベルが表示されるようになりました。 レコーダー/ストリーミング機能の詳細については、CMS 3.0リリースノート(https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Release_Notes/Version-3-0/Cisco-Meeting-Server-Release-Notes-3-0.pdf)を参照してください。
2.9.xでレコーダまたはストリーマを設定した場合、アップグレード後もこれらの設定が引き続き機能するように、MMPおよびAPIを再設定する必要があります。
CMSを3.0にアップグレードする前に、「backup snapshot <servername_date>」を使用してバックアップを取り、callbridgeノードのwebadminページにログインして、すべてのXMPP設定を削除することをお勧めします。 次に、サーバのMMPに接続し、SSH接続でxmppを使用するすべてのコアサーバで次の手順を実行します。
- xmppの無効化
- xmppリセット
- xmpp証明書なし
- xmppドメインなし
Recorder
MMP
図は、レコーダーが設定されたときにCMS 2.9.1で表示される設定の例と、3.0にアップグレードした直後の状態を示しています。
アップグレード後、レコーダーを再設定する必要があります。
ステップ 1：SIPリスニングインターフェイスを設定します。
recorder sip listen a 5060 5061（TCPおよびTLSをリッスンするようにSIPレコーダが設定されているインターフェイスおよびポート）。TLSを使用しない場合は、「recorder sip listen a 5060 none」を使用できます)。
ステップ 2：TLS接続を使用している場合にレコーダーが使用する証明書を構成します。
recorder sip certs <key-file> <crt-file> [crt-bundle](これらの証明書がないと、tlsサービスがレコーダで開始されません。レコーダはcrt-bundleを使用してcallBridge証明書を確認します)。
ステップ 3：コール制限を設定します。
recorder limit <0-500|none>(サーバで処理できる同時録音の最大数を設定します。この表はドキュメントに記載されており、レコーダーの制限はサーバ上のリソースと一致している必要があります)。
API
api/v1/callProfilesで、sipRecorderUriを設定する必要があります。これは、録音を開始する必要があるときにcallBridgeがダイヤルするURIです。このURIのドメインをアウトバウンドルールテーブルに追加し、使用するSIPプロキシとしてレコーダ（またはコール制御）をポイントする必要があります。
この図は、Configuration > Outbound Callsで検出された発信ルールのレコーダコンポーネントへの直接ダイヤルを示します。
この図は、コール制御(Cisco Unified Communications Manager(CUCM)やExpresswayなど)を介したレコーダコンポーネントへのコールを示しています。
複数のレコーダー？
説明に従って各ルールを設定し、それに応じて発信ルールを調整します。 レコーダに直接アクセスする方法を使用する場合は、既存のレコーダへの発信ルールを動作「Continue」に変更し、優先度が最初のルールよりも1低い前のルールの下に、新しい発信ルールを追加します。 最初のレコーダがコール制限に達すると、488 Inacceptable HereをcallBridgeに返信し、callBridgeは次のルールに進みます。
レコーダのロードバランシングを行う場合は、コール制御を使用し、コール制御ルーティングを調整して、複数のレコーダにコールを発信できるようにします。
ストリーマ
MMP
2.9.xから3.0にアップグレードした後、ストリーマを再設定する必要があります。
ステップ 1：SIPリスニングインターフェイスを設定します。
streamer sip listen a 6000 6001（TCPおよびTLSをリッスンするようにSIPストリーマが設定されているインターフェイスおよびポート）。 TLSを使用しない場合は、「streamer sip listen a 6000 none」を使用できます)
ステップ 2：TLS接続を使用している場合にストリーマが使用する証明書を設定します。
streamer sip certs <key-file> <crt-file> [crt-bundle](これらの証明書がないと、tlsサービスがストリーマで開始されません。ストリーマはcrt-bundleを使用してcallBridge証明書を確認します)。
ステップ 3：コール制限の設定
streamer limit <0-500|none>(サーバが処理できる同時ストリーム数の制限を設定します。この表はドキュメントに記載されており、ストリーマの制限はサーバ上のリソースと一致している必要があります)。
API
api/v1/callProfilesで、sipStreamUriを設定する必要があります。これは、ストリーミングを開始する必要があるときにcallBridgeがダイヤルするURIです。このURIのドメインをアウトバウンドルールテーブルに追加し、使用するSIPプロキシとしてストリーマ（またはコール制御）をポイントする必要があります。
この図は、Configuration > Outbound Callsで見つかる発信ルールのストリーマコンポーネントへの直接ダイヤルを示します。
この図は、コール制御(Cisco Unified Communications Manager(CUCM)やExpresswayなど)を介したレコーダコンポーネントへのコールを示しています。
複数のストリーマ？
説明に従って各ルールを設定し、それに応じて発信ルールを調整します。 直接ストリーマへの方式を使用する場合は、既存のアウトバウンドルールをレコーダへの転送ルールの動作が「Continue」に変更し、優先度が最初のルールよりも1低い新しいアウトバウンドルールを前のルールの下に追加します。 最初のストリーマがコール制限に達すると、488 Inacceptable HereをcallBridgeに返信し、callBridgeは次のルールに進む。
ストリーマのロードバランシングを行う場合は、コール制御を使用してコール制御ルーティングを調整し、複数のストリーマにコールを発信できるようにします。
Expresswayの考慮事項
WebプロキシにCisco Expresswayを使用する場合、CMSのアップグレードの前に、ExpresswayでX12.6以降が実行されていることを確認する必要があります。これは、Webプロキシが機能し、サポートされるためにCMS 3.0で必要です。
CMS 3.0と併用すると、ExpresswayよりもWebアプリ参加者のキャパシティが増加します。 大規模なOVA Expresswayの場合、予想される容量は150のフルHDコール(1080p30)または200のその他の種類のコール（たとえば720p30）です。この容量は、Expresswayを最大6ノードまでクラスタリングして増やすことができます（4は拡張に使用され、2は冗長性を確保するため、最大600のフルHDコールまたは他種類のコール）。
CMSエッジ
CMS Edgeは、外部Webアプリケーションセッション用にExpresswayよりも高い容量を提供するため、CMS 3.1に再導入されました。推奨される設定は2つあります。
スモールエッジ仕様
4 GB RAM、4 vCPU、1 Gbpsネットワークインターフェイス
このVM Edge仕様は、単一のCMS1000音声およびビデオロード容量（48 x 1080p、96 x 720p、192 x 480p、および1000音声コール）をカバーするのに十分な電力を備えています。
導入では、CMS1000ごとに1台のスモールエッジサーバ、またはCMS2000ごとに4台のスモールエッジサーバを使用することをお勧めします。
大規模エッジ仕様
8 GB RAM、16 vCPU、10 Gbpsネットワークインターフェイス
このVM Edge仕様は、350 X 1080p、700 X 720p、1000 X 480p、および3000 Xオーディオコールの単一のCMS2000オーディオおよびビデオキャパシティに対応するのに十分なパワーを備えています。
導入では、CMS2000またはCMS1000あたり4台のラージエッジサーバを1台使用することをお勧めします。
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
31-May-2021 |
初版 |
フィードバック