Cisco Meeting Server 2.9 から 3.0 以降へのスムーズなアップグレードのためのガイダンス
内容
はじめに
このドキュメントでは、バージョン2.9以前を実行しているCisco Meeting Server(CMS)の導入を3.0以降にアップグレードする際の課題と、スムーズなアップグレードプロセスのためにこれらの問題を処理する方法について説明します。
削除された機能:XMPPが削除されました（WebRTCに影響）、トランク/ロードバランサ、Webブリッジ
変更された機能：レコーダとストリーマは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はスマートライセンスを使用する必要があります。 CMS 3.4以降にアップグレードしても、従来のライセンスは使用できません。 スマートライセンスを設定していない限り、CMS 3.4以降にアップグレードしないでください。
検討事項の概要
次の質問を使用して、自分の状況に関連するセクションに移動します。 それぞれの考慮事項では、このドキュメントで説明されている詳細へのハイパーリンクを参照しています。
ライセンス
アップグレードの前に、サーバに十分なパーソナルマルチパーティ(PMP)/共有マルチパーティ(SMP)ライセンスがありますか。
3.0では、ユーザがサインインしていなくても、PMPライセンスが割り当てられます。たとえば、LDAPを介して10000ユーザをインポートしたが、PMPライセンスが100だけある場合、3.0にアップグレードするとすぐにコンプライアンスから外れます。 この使用例では、userProfileが設定されているテナントやsystem/profilesを確認して、値がtrueの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を導入することをお勧めします。これについては、このセクションで詳しく説明します。
Smart Licensingはありますか。
CMS 3.0では、ライセンスの処理方法が変更されたため、CMM 3.0が必要です。そのため、CMMを介してSmart Licensingをすでに使用している場合は、クラスタにPMPライセンスとSMPライセンスが関連付けられていることを確認します。
Webbridge（WebRTCおよびCMAクライアント）
CMS 2.9でWebRTCを使用していますか。
WebbridgeはCMS 3.0で大幅に変更されました。 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で完全に廃止されました。 CMSにSIPコールを取り込むには、Cisco Expresswayを使用する必要があります。組織のExpresswayの入手方法については、シスコの代理店にお問い合わせください。
詳細情報
ライセンス：アップグレード前にライセンスを確認する
コンプライアンス違反のライセンスのステータスは、2.xバージョンから3.0以降にアップグレードする際に最も影響を与える問題です。このセクションでは、スムーズなアップグレードに必要なPMP/SMPライセンスの数を決定する方法について説明します。
導入を3.0にアップグレードする前に、CMM 2.9を導入し、「Licenses」タブの下の「90 day report」をチェックして、ライセンスの使用状況が、CMSノードで現在割り当てられているライセンス金額を下回っていないかどうかを確認します。
従来のライセンス（cms.licファイルはCMSノードにローカルでインストールされます）を使用する場合は、CMSライセンスファイルで各CMSノードのパーソナルライセンスおよび共有ライセンス（この図では100/100）の数量を確認します（各callBridgeノードからWinSCPを介してダウンロード）。
すでにSmart Licensingを使用している場合は、CMSサーバのCisco Software Smartポータルで割り当てられているPMP/SMPライセンスの数を確認します。
90日レポート(Zipファイル名はlicense-data.zip)を開き、daily-peaks.csvという名前のファイルを開きます。
Excelで、PMP列をZでソートして上位の値を取得し、SMP列に対して同じ操作を実行します。 このファイルに表示される値は、CMSライセンスファイルで使用可能なライセンスよりも低いですか。「はい」の場合は、問題なく完全に準拠しています。そうでない場合は、CMS導入ガイドの図6のセクション1.7.3に示すように、警告やエラーが作成されます。このセクションの詳細は、セクション1.7.4にも記載されています。
図に示すように、過去90日間のピーク時には2.1667のSMPライセンスが使用され、PMPライセンスは使用されませんでした。cms.licファイルには、ライセンスのタイプごとに100ユニットと記載されているため、この設定は完全に準拠しています。したがって、この設定をCMS 3.0にアップグレードする場合は、ライセンスに関する問題はありません。ただし、セットアップでLDAPを介して10,000人のユーザがインポートされた場合に問題が発生する可能性があります。その時点ではPMPライセンスは100だけですが、10000を割り当てるため（hasLicenseをTrueに設定したuserProfileを使用）、3.0にアップグレードするとすぐにコンプライアンス違反になります。これについては、次のセクションで詳しく説明します。
アップグレード後にPMPライセンスが割り当てられるユーザ数の判別
hasLicense=trueでuserProfileをインポートして使用するすべてのユーザには、CMS 3.0でPMPライセンスが自動的に割り当てられます。
APIで、所有しているuserProfileの数と、これらのいずれかに「hasLicense=true」が設定されているかどうかを確認します。 割り当てられている場合は、そのユーザプロファイルが割り当てられている場所を確認する必要があります。
userProfilesは、次のレベルのいずれかで割り当てることができます。
- Ldapソース
- テナント
- システム/プロファイル
hasLicense=trueの割り当てられたuserProfilesの3つの場所すべてを確認します。
1. LdapSources/テナント
テナントまたは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がsystem/profilesレベルで設定されており、そのuserProfileが「hasLicense=true」である場合、サーバのアップグレード時にCMSにインポートされたすべてのユーザにPMPライセンスが割り当てられます。 10,000ユーザをインポートしたがPMPが100だけある場合、CMS 3.0にアップグレードする際にコンプライアンス違反が発生し、コールの開始時に30秒の画面メッセージと音声プロンプトが表示される可能性があります。
システムレベルのuserProfileがユーザがPMPを取得することを示している場合は、api/v1/usersに移動して、合計ユーザ数を確認します。
以前にすべてのユーザをLDAPからインポートしたことがあっても、リストから特定のサブセットだけが必要であることがわかっている場合は、PMPライセンスを割り当てるユーザだけをインポートするように、ldapSourceでより適切なフィルタを作成します。ldapSourceでフィルタを修正し、api/v1/ldapsyncで新しいLDAP同期を実行します。 これにより、目的のユーザだけがインポートされ、この以前のインポートの他のユーザはすべて削除されます。
十分な数のSMPライセンスがありますか。
CMM 90 Day Reportで毎日のピークを確認した際に、ピーク時の対応に十分なSMPライセンスを既にお持ちですか？ SMPライセンスは、会議の所有者にPMPライセンスが割り当てられていない場合（coSpace所有者、アドホック会議、TMSスケジュール会議など）に使用されます。 意図的にSMPを使用していて、ピーク時間をカバーするのに十分な時間があれば、これはすべてOKです。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 certs none（証明書なし）
- xmppドメインなし
- webbridgeの無効化
- webbridge listen none
- webbridge certsなし
- webbridge trustなし
3.0にアップグレードしたら、以前webbridgeを実行していたすべてのサーバでwebbridge3を設定することから始めます。 これらのサーバを指すDNSレコードがすでに存在するため、これを行う必要があります。このようにすると、ユーザがwebbridge3に送信された場合、要求を処理する準備が確実に整います。
Webbridge3の設定（すべてのSSH接続経由）
ステップ 1：webbridge3 httpリスニングポートを設定します。
Webbridge3 httpsリッスンa:443
ステップ 2：ブラウザ接続用のwebbridge3の証明書を設定します。 これはブラウザに送信される証明書であり、ブラウザが接続を信頼するためにブラウザで使用されるFQDNを含むパブリック認証局(CA)によって署名される必要があります。
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 trust rootca.cer
6. webbridge3を有効にします
Webbridge3の有効化
CallBridge設定の変更（すべてのSSH接続）
ステップ 1：webbridge3 c2w証明書に署名したCA証明書/バンドルを使用してcallBridge trustを設定します。
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アプリユーザは、コスペーステンプレートが割り当てられていない限り、独自のコスペースを作成することはできません。
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からWebブリッジ設定の一部が削除または再配置されています。ユーザに一貫したエクスペリエンスを提供するには、これらの設定をAPIで設定する必要があります。 3.xでは、api/v1/webBridgesおよびapi/v1/webBridgeProfilesを使用します。
現在の設定内容を確認して、3.0にアップグレードするときに、それに応じてAPIでwebbridgeおよびwebbridgeプロファイルを設定できるようにします。
3.0では、GUIでWeb bridge settingsが削除され、CMS 3.1ではExternal accessフィールドも削除されています。
GUIでのWebブリッジの設定
- ゲストアカウントクライアントURI：これはwebBridgeを見つけるためにcallBridgeによって使用されました。 WebRTCの配備に複数のwebBridgeがある場合、このフィールドはブランクである必要があり、callBridgeが接続する必要がある各webBridgeのapi/v1/webbridgesに一意のURLが必要です。 このフィールドの内容をすべて削除し、APIでwebBridgesが設定されていることを確認します。
- Guest Account Jid Domain：これはCMS 3.0では使用されなくなったため、削除できます。
- IDおよびパスコードによるゲストアクセス:CMS 3.0では削除され、置き換えられませんでした。
- Hyper Links経由のゲストアクセス:APIのwebBridgeProfilesで「AllowSecrets」を設定することで設定可能になりました。
CMS 3.0では、複数のフィールドがapi/v1/webBridgesから削除されています。
- resourceArchive:webbridgeProfilesに追加されました。
- idEntryMode：現在推奨されていません。
- allowWeblinkAccess:allowSecretsとしてwebBridgeProfilesに追加されました。
- showSignin:userPortalEnabledとしてwebBridgeProfilesに追加されました。
- 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の場合、サインインできるユーザーのみが会議に参加できます。 例： User2はUser1の会議のURLを使用しようとしています。 URLを入力した後、User2はUser1の会議を続行するためにサインインする必要があります。
- resolveCoSpaceCallIds:Falseに設定すると、ゲストはURIとPIN/パスコード（使用している場合）を入力することによってのみ会議に参加できます。 コールID/会議ID/数値IDは受け付けられません。
- resolveCoSpaceUris:off、domainSuggestionDisabled、およびdomainSuggestionEnabledの3つの設定が可能です。ビジターがCoSpace会議に参加することを許可するために、このWebBridgeがCoSpaceおよびCoSpace accessMethod SIP URIを受け入れるかどうか。
- 'off'に設定すると、URIによる参加が無効になります。
- 「domainSuggestionDisabled」に設定されている場合、URIによる参加が有効になりますが、このwebBridgeProfileを使用してwebBridgeでURIのドメインが自動完了または確認されることはありません。
- 「domainSuggestionEnabled」に設定すると、URIによる参加が有効になり、このwebBridgeProfileを使用してwebBridgeでURIのドメインを自動完了して確認できます。
Web GUIから削除されたExternal Accessセクション
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 certs none（証明書なし）
- xmppドメインなし
Recorder
MMP
図は、レコーダーが設定された時点でのCMS 2.9.1での設定例と、3.0へのアップグレード直後の状態を示しています。
アップグレード後に、レコーダを再設定する必要があります。
ステップ 1：SIPリスニングインターフェイスを設定します。
recorder sip listen a 5060 5061（SIPレコーダがTCPおよびTLSをリッスンするように設定されているインターフェイスとポート）。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仕様は、1台のCMS1000音声およびビデオロード容量（48 x 1080p、96 x 720p、192 x 480p、および1000音声コール）をカバーするのに十分なパワーを備えています。
導入には、CMS1000ごとに1台のスモールエッジサーバ、またはCMS2000ごとに4台のスモールエッジサーバを使用することをお勧めします。
大規模エッジ仕様
8 GB RAM、16 vCPU、10 Gbpsネットワークインターフェイス
このVM Edge仕様は、1台のCMS2000音声およびビデオキャパシティ（350 X 1080p、700 X 720p、1000 X 480p、および3000 X音声コール）をカバーするのに十分なパワーを備えています。
導入では、CMS2000またはCMS1000あたり4台のラージエッジサーバを使用することを推奨します。
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
31-May-2021 |
初版 |
フィードバック