كيفية نقل مستخدمي تطبيق ويب من Spaces/Meetings في CMS

المقدمة

يصف هذا المستند القدرة على نقل المشاركين من إجتماع إلى آخر بواسطة إدارة إجتماعات Cisco (CMM). يمكن لمسؤول CMM نقل المشاركين في تطبيق ويب بين الاجتماعات التي لها جسور اتصال واحدة أو مختلفة.

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• المعرفة الأساسية لخادم الاجتماعات (CMS) من Cisco.
• المعرفة الأساسية ل CMM.
• المعرفة الأساسية لتطبيق ويب CMS.

المكونات المستخدمة

تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:

• CMS الإصدار 3. 2.
• CMM الإصدار 3. 2.
• CMS Web App، الإصدار 3.2.
• متصفح الويب كروم 91.

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

التكوين

معلومات أساسية

تظهر القدرة على نقل المشاركين من إجتماع إلى آخر بواسطة CMM في الأصل في CMS 2.6 ولكن مع بعض القيود، أي لا يمكن نقل المشاركين في تطبيق الاجتماعات وتطبيق الويب و Skype for Business (SFb). بداية ب CMS 3.2، يمكن لمسؤول CMM نقل المشاركين في تطبيق ويب بين الاجتماعات التي لها جسور اتصال واحدة أو مختلفة.

ملاحظة: لا تعني هذه الميزة أنه يمكن للمشاركين في تطبيق ويب إستدعاء نقل للمشاركين الآخرين. في السابق، عند محاولة نقل المشاركين في تطبيق ويب، يقوم CMM بمنع ذلك باستخدام تنبيه. يتم اكتشاف هذا التقييد تلقائيا بواسطة CMM حيث يتم إستضافة الاجتماع على CMS 3.2 ويتم السماح بتحريكه.

الرسم التخطيطي للشبكة

التكوينات

الخطوة 1. تقوم CMM باستدعاء واجهة برمجة التطبيقات (API) إلى CallBridge B باستخدام أسلوب POST /CALLS/<call_X_id>/participants/ مع "movedParticipant"=participant_a_guid.

الخطوة 2. يقوم CallBridge B بإرسال طلبات نقل المشارك إلى CallBridge A.

الخطوة 3. تستجيب CallBridge A مع إعادة طلب النقل إلى CallBridge B.

الخطوة 4. تقوم CallBridge B بتوزيع الحمل وتقرر وضع مشترك جديد في CallBridge C.

الخطوة 5. يقوم CallBridge B بإرسال طلب إلى CallBridge C لإنشاء مثيل مشارك ومشارك جديدين. بالنسبة للضيف، يتم إنشاء معرف ضيف جديد. يحتوي مثيل المشارك الجديد على رموز JWT مميزة جديدة ل JASON Web.

الخطوة 6. CallBridge C يرسل واجهة برمجة التطبيقات (API) نقل رسالة مأخذ ويب عبر إستدعاء Bridge إلى Web Bridge (C2W) إلى WebBridge A.

الخطوة 7. يرسل WebBridge A رسالة نقل مأخذ ويب إلى عميل WebBridge (WC3) في المستعرض.

الخطوة 8. يرسل WC3 في المستعرض رسالة نهاية مأخذ ويب إلى WebBridge A.

الخطوة 9. يقوم WebBridge A بإعادة توجيه رسالة جلسة عمل النهاية إلى CallBridge A.

الخطوة 10. CallBridge A يدمر مثيل المشارك و JWT القديم.

الخطوة 11. يقوم عميل WC3 الموجود في المستعرض بالمصادقة في رسالة مأخذ توصيل ويب جديدة إلى WebBridge A واستخدام JWT جديد.

التحقق من الصحة

فيما يلي نموذج لرسائل السجل التي يتم فيها نقل مشارك الويب الضيف من مساحة 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"

احذف ضيف المستخدم القديم921953266 وقلل المكالمة السابقة، اتصل ب 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

عندما يستلم تطبيق ويب طلب نقل، يقوم بقطع اتصال المكالمة الحالية، ثم يبدأ عملية الانضمام مرة أخرى باستخدام JWT الجديد. بعد النقل، يرى المشارك الرسالة التي قمت بنقلها إلى مكالمة جديدة في الركن السفلي الأيمن تشير إلى أن المكالمة الآن في إجتماع جديد كما هو موضح في الصورة التالية. النص بعد الرسالة الآن، هو اسم المسافة في هذه الحالة Space 2.

يتم نقل بعض حالة إجتماع تطبيق ويب المحلي مثل كتم الصوت والتخطيط من المكالمة السابقة. على سبيل المثال، إذا قام المشارك بالكتابة محليا فإنه يبقى مكتوما في المكالمة الجديدة.

لا يتم نقل الميزات التالية إلى المكالمة الجديدة:

• عرض تقديمي - عند نقل المشارك، يتم إسقاط العرض التقديمي النشط. وفي الاجتماع الجديد الذي يعقد بعد الانتقال، لا يشارك المشارك.
• رسائل الدردشة - تتم إزالة رسائل الدردشة السابقة من الدردشة ولا يتم نقلها إلى الاجتماع الجديد.

استكشاف الأخطاء وإصلاحها

المشكلة: لا يتم نقل المشارك في تطبيق ويب.

قد يعني الكثير من الأشياء:

1. لم يحدث شيء. لا يزال الاتصال متصلا بالمكالمة الأولى.
2. تم الإسقاط ولكن لم يتم إعادة الاتصال. تم إسقاط المكالمة ولكنها لا تتصل بالمكالمة الثانية.
3. الاتصال بالاجتماع الخطأ.

للسيناريو أ. ما صار شي:

• تأكد من أن جسر المكالمة يتلقى طلب النقل من CMM. راجع رسائل سجل CMS للحصول على كلمة أساسية محددة مثل عملية نقل المشارك. إذا لم يستلم CMS واجهة برمجة تطبيقات من CMM، فقم بتنفيذ الخطوات الأساسية لاستكشاف الأخطاء وإصلاحها بين CMM و CMS متضمنا تتبع API ممكن على كلا الجانبين، تحققات خدمة اسم المجال (DNS)، والتحقق من الاتصال.
• راجع ما إذا كان قد تم تعيين المعلمة canMove في /participants/<participant id> أو /callLegs/<callLeg id> إلى true.

بالنسبة للسيناريو ب. تم الإسقاط ولكن لم تتم إعادة الاتصال:

• تأكد من أن قطع الاتصال بسبب نقل، أي ابحث عن نقل عملية المشارك في السجل.
• في سجلات CMS، ابحث عن أخطاء/انسداد الموارد على جسر الاتصال الذي قد يمنع عملية إنشاء المشارك.
• هل لدى المشارك إذن للانضمام إلى الحيز المساعد الجديد؟
• هل هناك خطأ في JWT؟
• حاول الانضمام إلى الاجتماع يدويا.

بالنسبة للسيناريو ج. الاتصال بالاجتماع الخطأ:

في ملف تنسيق أرشيف بروتوكول نقل النص التشعبي (HTTP)، راجع مقبس الويب الخاص بالمكالمة الأولى، تظهر بيانات طريقة الوصول الخاصة ب POST /api/call/session/move المعرف الرقمي الذي يتم إستخدامه للاتصال بالمكالمة الجديدة. تأكد من أن هذا المعرف الرقمي هو الاجتماع المقصود.