概要
このドキュメントでは、Cisco Meeting Management(CMM)を使用して、参加者をある会議から別の会議に移動する機能について説明します。CMM管理者は、同じまたは異なるコールブリッジのミーティング間でWebアプリの参加者を移動できます。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- Cisco Meeting Server(CMS)の基礎知識
- CMM基礎知識
- CMS Webアプリの基礎知識。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- CMSバージョン3.2
- CMMバージョン3.2
- CMS Webアプリバージョン3.2.
- Webブラウザchrome 91.
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
設定
背景説明
CMMによる会議から別の会議への参加者の移動は、元々CMS 2.6で行われていますが、Meeting App、Webアプリ、Skype for Business(SfB)の参加者は移動できません。CMS 3.2から開始すると、CMM管理者は同じコールブリッジまたは異なるコールブリッジの会議間でWebアプリの参加者を移動できます。
注:この機能は、Webアプリの参加者が他の参加者の移動を呼び出せることを意味するものではありません。以前は、Webアプリの参加者を移動しようとすると、CMMは警告を表示してこれを防止していました。この制限はCMMによって自動的に検出され、会議はCMS 3.2でホストされ、移動できます。
ネットワーク図
設定
ステップ1:CMMは、メソッドPOST /calls/<call_X_id>/participants/with "movedParticipant"=participant_A_guidを使用して、Application Programming Interface(API)をCallbridge Bに呼び出します。
ステップ2:Callbridge Bが参加者の移動要求をCallbridge Aに送信します。
ステップ3:Callbridge AがCallbridge Bに移動要求で応答します。
ステップ4:Callbridge Bはロードバランスを行い、新しい参加者をCallbridge Cに配置することを決定します。
ステップ5:Callbridge BがCallbridge Cに要求を送信し、新しい参加者インスタンスと参加者を作成します。guestの場合、新しいゲストIDが作成されます。新しい参加者インスタンスに新しいJASON Web Tokens(JWT)があります。
ステップ6:Callbridge CがCall BridgeからWeb Bridgeへ(C2W)のAPI move Web socketメッセージをWebbridge Aに送信します。
ステップ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を使用して再び参加プロセスを開始します。移動後、次の図に示すように、参加者には「新しいコールに移動しました。コールが新しい会議に参加していることを示すメッセージが右下隅に表示されます。Now inメッセージの後に続くテキストは、この場合はSpace 2のスペース名です。
ミュートやレイアウトなど、一部のローカルWebアプリの会議の状態は、前のコールから引き継がれます。たとえば、参加者がローカルでミュートされている場合、新しいコールではミュートのままになります。
次の機能は、新しいコールに引き継がれません。
- プレゼンテーション:参加者を移動すると、アクティブなプレゼンテーションが破棄されます。移動後の新しい会議では、参加者は共有しません。
- チャットメッセージ:以前のチャットメッセージはチャットから削除され、新しい会議に転送されません。
トラブルシュート
問題:Webアプリの参加者は移動されません。
これは多くのことを意味します。
- 何もなかった。コールは最初のコールに接続されたままです。
- 切断されましたが、再接続されませんでした。コールはドロップされますが、2番目のコールには接続されません。
- 間違った会議に接続します。
シナリオa.何も起こらなかった:
- Call BridgeがCMMからの移動要求を受信していることを確認します。参加者の移動操作などの特定のキーワードについては、CMSログメッセージを参照してください。CMSがCMMからAPIを受信しない場合は、CMMとCMS間で基本的なトラブルシューティングを行い、両側で有効なAPIトレース、ドメインネームサービス(DNS)チェック、接続チェックを行います。
- /participants/<participant id>または/callLegs/<callLeg id>のcanMoveパラメータがtrueに設定されているかどうかを確認します。
シナリオb.ドロップされましたが再接続していません:
- 移動が原因で切断されていることを確認します。つまり、ログで参加者の移動操作を探してください。
- CMSログで、参加者の作成プロセスが行われない可能性があるコールブリッジのリソースエラーまたはブロックを探します。
- 参加者に新しいコスペースに参加する権限がありますか?
- JWTにエラーがありますか?
- 手動で会議に参加してみてください。
シナリオc.間違った会議に接続する:
Hyper Text Transport Protocol (HTTP) Archive Format (HAR)ファイルで、最初の呼び出しのWebソケットを調べます。POST /api/call/session/moveのアクセスメソッドデータは、新しい呼び出しに接続するために使用される数値IDを示します。この数字のIDが目的の会議であることを確認します。