CMSのスペース/ミーティングからWebアプリケーションユーザを移動する方法

はじめに

このドキュメントでは、Cisco Meeting Management(CMM)を使用して参加者を1つの会議から別の会議に移動する機能について説明します。 CMM管理者は、同じまたは異なるCall Bridgeの会議間でWebアプリ参加者を移動できます。

前提条件

要件

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

• Cisco Meeting Server(CMS)の基礎知識
• CMMの基礎知識
• CMS Web Appの基礎知識。

使用するコンポーネント

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

• CMSバージョン3.2
• CMMバージョン3.2
• CMS Web Appバージョン3.2
• Webブラウザchrome 91。

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

設定

背景説明

CMMによって参加者をある会議から別の会議に移動する機能は、CMS 2.6で最初に導入されましたが、いくつかの制限があります。つまり、会議アプリ、Webアプリ、およびSkype for Business (SfB)の参加者は移動できません。CMS 3.2から、CMM管理者は同じまたは異なるCall Bridgeの会議間でWebアプリケーション参加者を移動できます。

注：この機能は、Webアプリの参加者が他の参加者の移動を呼び出せるという意味ではありません。以前は、Webアプリの参加者を移動しようとすると、CMMによってアラートが表示されてこれを防ぐことができました。この制限はCMMによって自動的に検出され、会議はCMS 3.2でホストされ、移動が許可されます。

ネットワーク図

コンフィギュレーション

ステップ 1：CMMは、メソッドPOST /calls/<call_X_id>/participants/(「movedParticipant」=participant_A_guid)を使用して、アプリケーションプログラミングインターフェイス(API)コールをCallbridge Bに発信します。

ステップ 2：Callbridge Bが参加者の移動要求をCallbridge Aに送信します。

ステップ 3：コールブリッジAがコールブリッジBに移動要求で応答します。

ステップ 4：Callbridge Bはロードバランスを行い、新しい参加者をCallbridge Cに配置することを決定します。

ステップ 5：Callbridge BがCallbridge Cにリクエストを送信し、新しい参加者インスタンスと参加者を作成します。guestには、新しいゲストIDが作成されます。新しい参加者インスタンスに新しいJASON Web Tokens(JWT)が追加されました。

手順 6：Callbridge CがCall Bridge経由でWebbridge AへAPI move web socketメッセージを送信(C2W)。

手順 7：Webbridge Aは、ブラウザのWebbridgeクライアント(WC3)にmove web socketメッセージを送信します。

ステップ 8：ブラウザのWC3がWebbridge Aにend web socketメッセージを送信します。

ステップ 9：Webbridge AがエンドセッションメッセージをCallbridge Aに転送します。

ステップ 10：Callbridge Aは参加者インスタンスと古いJWTを破棄します。

ステップ 11ブラウザ内のWC3クライアントは、Webbridge Aへの新しいWebソケットメッセージで認証し、新しいJWTを使用します。

確認

次に、ゲストWeb参加者をSpace 1(webapp.com)スペースからSpace 2(webapp.com)スペースに移動したログメッセージの例を示します。フローを簡素化するために、異なるスペースへの移動は同じコールブリッジcbcms2上に残ります（クラスタはロードバランシングされます）。

まず、API POST /calls/<call id>/participantsで移動フローが始まります。

2021-03-04  15:50:03.915  Info     API trace 42003: POST for "/api/v1/calls/ae778701-7fed-410c-b3e6-c2860907a3f4/participants" (from 172.19.233.174)
2021-03-04  15:50:03.915  Info     API trace 42003: content data size 75, type "application/x-www-form-urlencoded":
2021-03-04  15:50:03.915  Info     API trace 42003:  movedParticipant=26de0160-30b5-4d7b-8a05-304472a
2021-03-04  15:50:03.915  Info     API trace 42003:      f284a&
2021-03-04  15:50:03.915  Info     API trace 42003:  needsActivation=false

参加者を別のコールに移動し、最初に新しいゲストアカウント(guest2316075499)を作成します。

2021-03-04  15:50:03.915  Info     move participant operation: moving WC3 participant 26de0160-30b5-4d7b-8a05-304472af284a (guest921953266) (homed on this callbridge) to call ae778701-7fed-410c-b3e6-c2860907a3f4
2021-03-04  15:50:03.915  Info     guest login request 0: credential storage scheduled (queue length: 1)
2021-03-04  15:50:03.915  Info     created guest account with user ID "guest2316075499"
2021-03-04  15:50:03.915  Info     guest login request 0: credential storage executed
2021-03-04  15:50:03.915  Info     guest login request 0: credential storage in progress
2021-03-04  15:50:03.921  Info     guest login request 0: successfully stored credentials
2021-03-04  15:50:03.921  Info     replace query for conference c3958a89-3007-4959-99e7-f6ea84609aac: response from 'cbcms2' (priority: 0, load level: 0, conference is running: 1)
2021-03-04  15:50:03.921  Info     replace query for conference c3958a89-3007-4959-99e7-f6ea84609aac: using local server 'cbcms2' (priority: 0, load level: 0, conference is running: 1)
2021-03-04  15:50:03.921  Info     API call leg dd2bc8c6-fa80-495f-9a20-1da19010cfab in call c0cc4e15-bb74-4af3-948b-672c9571c7fc (API call ae778701-7fed-410c-b3e6-c2860907a3f4)
2021-03-04  15:50:03.922  Info     172.19.233.174: API user "admin" created new participant dd2bc8c6-fa80-495f-9a20-1da19010cfab, call ae778701-7fed-410c-b3e6-c2860907a3f4
2021-03-04  15:50:03.922  Info     API trace 42003: sending 200 response, size 0
2021-03-04  15:50:03.922  Info     API trace 42003: Location: /api/v1/participants/dd2bc8c6-fa80-495f-9a20-1da19010cfab
2021-03-04  15:50:03.923  Info     new session created for user "guest2316075499"
2021-03-04  15:50:03.923  Info     instantiating user "guest2316075499"

古いユーザguest921953266を削除し、以前のコールコール19をティアダウンします。

2021-03-04  15:50:03.947  Info     user "guest921953266": deactivating due to session resource teardown
2021-03-04  15:50:03.948  Info     call 19: tearing down ("guest921953266" conference media)
2021-03-04  15:50:03.948  Info     participant "guest921953266" left space 89eae70d-5b67-41fc-97f7-38a655fa6467 (Space 1 (webapp.com))
2021-03-04  15:50:03.948  Info     call 19: destroying API call leg 26de0160-30b5-4d7b-8a05-304472af284a
2021-03-04  15:50:03.948  Info     removing guest account 'guest921953266' (name 'User X') on call drop
2021-03-04  15:50:03.948  Info     destroying guest account with user ID "guest921953266"

新しいコール(コール20)のメディアセッションが正常にセットアップされました。

2021-03-04  15:50:04.106  Info     call 20: allocated for guest2316075499 / "User X" conference participation (Chrome)
2021-03-04  15:50:04.106  Info     call 20: removing h264 from video codec bitmask, because it's Chrome web client and we're using a compatibility profile
2021-03-04  15:50:04.106  Info     call 20: configured - API call leg dd2bc8c6-fa80-495f-9a20-1da19010cfab
2021-03-04  15:50:04.107  Info     call 20: setting up combined RTP session for DTLS (combined media and control)
2021-03-04  15:50:04.108  Info     participant "guest2316075499" joined space 59b9e43e-b277-4d33-a244-e896d20f2049 (Space 2 (webapp.com))
2021-03-04  15:50:04.108  Info     participant "guest2316075499" (dd2bc8c6-fa80-495f-9a20-1da19010cfab) joined conference c0cc4e15-bb74-4af3-948b-672c9571c7fc via WB3

Webアプリケーションは移動要求を受信すると、現在のコールを切断し、新しいJWTで参加プロセスを再開します。移動の後、右下隅に参加者に「You been moved to a new call」というメッセージが表示されます。このメッセージは、次の図に示すように、コールが新しい会議に参加していることを示しています。Now inメッセージの後のテキストは、この例ではSpace 2のスペース名です。

ミュートやレイアウトなど、ローカルWebアプリの会議の状態の一部は、前の通話から引き継がれます。たとえば、参加者がローカルでミュートしている場合、新しいコールでもミュートされたままになります。

次の機能は、新しいコールには引き継がれません。

• Presentation：参加者が移動されると、アクティブなプレゼンテーションはドロップされます。移動後の新しい会議では、参加者は共有しません。
• チャットメッセージ：以前のチャットメッセージはチャットから削除され、新しい会議に転送されません。

トラブルシュート

問題： Webアプリケーションの参加者が移動しません。

これは多くのことを意味します。

1. 何も起こらなかった。コールは最初のコールに接続されたままです。
2. 切断されたが再接続されない。コールはドロップされるが、2番目のコールに接続されない。
3. 誤った会議に接続する

シナリオa.何も起こらない場合:

• Call BridgeがCMMからの移動要求を受信することを確認します。参加者の移動などの特定のキーワードについては、CMSログメッセージを参照してください。CMSがCMMからAPIを受信しない場合は、CMMとCMS間の基本的なトラブルシューティングを行います。これには、両側で有効になっているAPIトレース、ドメインネームサービス(DNS)チェック、接続チェックが含まれます。
• /participants/<participant id>または/callLegs/<callLeg id>のcanMoveパラメータがtrueに設定されているかどうかを確認します。

Dropped but not reconnectの場合：

• 移動が原因で接続解除が発生していることを確認します。つまり、ログで参加者の移動操作を探します。
• CMSログで、参加者の作成プロセスを妨げる可能性があるリソースエラーまたはブロックをCall Bridge上で探します。
• 参加者には新しいCospaceに参加する権限がありますか。
• JWTにエラーはありますか？
• 手動で会議に参加してみます。

シナリオc.間違った会議に接続する:

Hyper Text Transport Protocol(HTTP)Archive Format(HAR)ファイルで、最初のコールのWebソケットを確認します。POST /api/call/session/moveのアクセス方式データには、新しいコールへの接続に使用される数値IDが示されます。この数値IDが、目的の会議の数値IDであることを確認します。