如何從CMS中的空間/會議中移動Web應用使用者

簡介

本文檔描述了通過思科會議管理(CMM)將參與者從一個會議移動到另一個會議的能力。CMM管理員可以在相同或不同呼叫網橋的會議之間移動Web應用參與者。

必要條件

需求

思科建議您瞭解以下主題：

• 思科會議伺服器(CMS)基礎知識。
• CMM基礎知識。
• CMS Web應用基礎知識。

採用元件

本文中的資訊係根據以下軟體和硬體版本：

• CMS版本3.2。
• CMM版本3.2.
• CMS Web應用版本3.2。
• Web瀏覽器Chrome 91。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

設定

背景資訊

CMM將參與者從一個會議移動到另一個會議的功能最初在CMS 2.6中提供，但存在一些限制，即無法移動會議應用、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方法對Callbridge B進行應用程式程式設計介面(API)呼叫。

步驟2. Callbridge B將參與者移動請求傳送到Callbridge A。

步驟3. Callbridge A將移動請求回復到Callbridge B。

步驟4. Callbridge B進行負載平衡，並決定向Callbridge C新增新參與者。

步驟5. Callbridge B向Callbridge C傳送請求，以建立新的參與者例項和參與者。對於訪客，會建立新的訪客ID。新的參與者例項具有新的JASON Web令牌(JWT)。

步驟6. Callbridge C將API move web socket消息通過呼叫網橋傳送到Web Bridge(C2W)到Web Bridge A。

步驟7. Webbridge A將move Web socket訊息傳送到瀏覽器中的Webbridge Client(WC3)。

步驟8.瀏覽器中的WC3將end web socket消息傳送到Webbridge A。

步驟9. Webbridge A將結束會話消息轉發到Callbridge A。

步驟10. Callbridge A銷毀參與者例項和舊JWT。

步驟11.瀏覽器中的WC3客戶端在發給Webbridge A的新Web套接字消息中驗證並使用新的JWT。

驗證

下面是訪客Web參與者從空間1(webapp.com)空間移動到空間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 have been moved to a new call（您已移動到新呼叫）」 ，這表示該呼叫現在位於新會議中，如下圖所示。Now in消息後的文本是本例中的空格Space 2。

某些本地Web應用會議狀態（如靜音和佈局）是從上一個來電轉駁的。例如，如果參與者在本地靜音，則在新的呼叫中仍保持靜音。

後續功能不會轉移到新呼叫：

• 演示 — 移動參與者時，會丟棄活動的演示。在移動後的新會議中，參與者不共用。
• 聊天消息 — 以前的聊天消息將從聊天中刪除並且不會轉移到新會議。

疑難排解

問題：Web應用參與者不會被移動。

這可能意味著很多事情：

1. 什麼都沒發生。該呼叫仍連線到第一個呼叫。
2. 已刪除，但未重新連線。該呼叫被丟棄，但無法連線到第二個呼叫。
3. 連線到錯誤的會議。

對於場景a，沒有發生任何事情：

• 確保呼叫網橋收到來自CMM的轉移請求。有關特定關鍵字（如移動參與者操作），請參閱CMS日誌消息。如果CMS沒有從CMM接收API，則在CMM和CMS之間執行基本故障排除，包括兩端已啟用的API跟蹤、域名服務(DNS)檢查、連線檢查。
• 檢視/participants/<participant id>或/callLegs/<callLeg id>中的canMove引數是否設定為true。

對於方案b。已丟棄但未重新連線:

• 確保斷開連線是由於移動造成的，即在日誌中查詢移動參與者操作。
• 在CMS日誌中，在呼叫網橋上查詢可能阻止參與者建立進程發生的資源錯誤/阻塞。
• 參與者是否具有加入新共用空間的許可權？
• JWT是否有錯誤？
• 嘗試手動加入會議。

對於情況c。連線到錯誤的會議:

在超文本傳輸協定(HTTP)存檔格式(HAR)檔案中，檢視第一次呼叫的Web套接字，POST /api/call/session/move的訪問方法資料顯示用於連線到新呼叫的數字ID。確保此數字ID是預定會議的數字ID。