المقدمة
يصف هذا وثيقة الكشف والعمل حول cisco بق id CSCvt73723 حول WebRTC نادل يسرب جلسة بعد كمية كبيرة من جلسة وضعت على النادل. قد يؤدي ذلك في نهاية المطاف إلى عدم قدرة المستخدمين على تسجيل الدخول أو الانضمام كضيف على WebBridge.
المتطلبات الأساسية
المتطلبات
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
- خادم الاجتماعات (CMS) من Cisco (مكون CallBridge و WebBridge)
المكونات المستخدمة
تستند المعلومات الواردة في هذا المستند إلى خادم الاجتماعات من Cisco وعلى وجه الخصوص حول مكون WebBridge 2 / CMA WebRTC. لا ينطبق هذا المستند على مكون WebBridge 3 / CMS Web App الجديد الذي تم تقديمه في الإصدار 2.9.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
CSCvt73723 - جلسات تسريب خادم WebRTC بعد عدد كبير من جلسات العمل التي تم عقدها على الخادم
كيف تتعرف على هذا الخطأ؟
تتمثل الأعراض من منظور المستخدم النهائي بمجرد الوصول إلى الحد الأقصى ولا يمكن لأي مستخدمين آخرين الانضمام إلى إجتماع. في السجلات، تصل عمليات الكشف عن حالات WebBridge (وفقا لهذه الأسئلة المتداولة) إلى 149 لا تعني بالضرورة أن هذه كلها جلسات مسربة. هذا يعني فقط أن Web Bridge قد وصل إلى الحد الأقصى المسموح به، ولا يتم السماح بأي إتصالات جديدة.
"webbridge": معلومات: [تصحيح الأخطاء] الإحصائيات 149 و c:3477 و d:3170
إن حساب عدد هذه الجلسات المسربة أكثر تعقيدا بقليل ويمكن القيام به إذا لم تكن تستخدم عميل CMA Desktop أو عميل iOS. من الإصدار 2.8، يقوم Call Bridge بالإبلاغ كل 5 دقائق عن عدد جلسات عمل CMA (CMA WebRTC + عميل CMA Desktop + عميل CMA iOS). لاحظ أنه يتم الإبلاغ عن هذا ك "CMA": "X/Y" حيث يمثل X العدد الحالي لجلسات عمل CMA النشطة و Y هو الحد الأقصى في الخمس دقائق الأخيرة.
معلومات: البيانات: {"callLegsPS": 1، "callLegs": "20/24"، "cma": "14/17"، "sip": {"std": "0/1"، "peer": "6/6"}
لمجرد أن Call Bridge يقوم بالإبلاغ عن 14 جلسة حالية لا يعني أن Web Bridge الموقع المشترك يقوم أيضا بالإبلاغ عن 14 جلسة. هذا التعيين هو 1:1 على خادم مدمج واحد ولكن في نشر مجمع يمكن لجلسة عمل Web Bridge إنشاء مثيل لمكالمة على جسر اتصال مختلف (خاصة عندما يتم تمكين موازنة الأحمال - وهو ما يتم بشكل افتراضي ل CMA).
لذلك، ومن أجل حساب العدد الإجمالي للجلسات المسربة في عملية نشر، تحتاج إلى جلسات العمل النشطة المجمعة من جميع حالات Web Bridge ومقارنة هذا مع حالات CMA Call Bridge المجمعة التي يتم الإبلاغ عنها.
كيف يمكنكم تجنب هذه المسألة؟
بناء على عدد مرات نجاح عملية النشر الخاصة بك في هذه الحالة (مرة كل يومين أو مرة كل أسبوعين)، يجب نصحك بإعادة تشغيل Web Bridge (الجسور) الخاصة بهم والتي تعمل على مسح أي جلسات مسربة وإعادة تعيين عدد جلسات العمل النشطة إلى 0. وبشكل مفهوم، يمكن أن يكون هذا الأمر مملا إذا أصبح عبء عمل يومي، وبالتالي لماذا يمكن تسهيل هذه المهمة من خلال نص متاح وفقا لكتلة الرمز.
################################################################
#### Cisco Meeting Server ####
#### Webbridge restart ####
#### Workaround for CSCvt73723 ####
#### feedback: willwoo@cisco.com ####
################################################################
#--------------------------------------------------------------
# ---------- DISCLAIMER ----------
#--------------------------------------------------------------
# Please note this script is NOT maintained or supported by Cisco.
# This is to be run at entirely your own risk.
# This script is not intended for redistribution
# Tested with python 3.7.4
#--------------------------------------------------------------
#--------------------------------------------------------------
# ---------- Libraries to import ----------
#--------------------------------------------------------------
import paramiko
import time
import datetime
#--------------------------------------------------------------
#--------------------------------------------------------------
# ---------- Deployment parameters to change ----------
#--------------------------------------------------------------
# WB Inventory - just extend or modify the below to match your deployment requirements.
# Enter the MMP IP of the server (can differ from interface webbridge service is running)
webbridges ={1:"127.0.0.1",2:"127.0.0.1",3:"127.0.0.1",4:"127.0.0.1"}
mmp_username = "admin" # MMP username
mmp_password = "password" # MMP password
#--------------------------------------------------------------
def mmp_webbridge_restart(mmp_address,uname,pword):
conn = paramiko.SSHClient()
conn.set_missing_host_key_policy(paramiko.AutoAddPolicy())
try:
conn.connect(mmp_address, 22, uname, pword)
stdin, stdout, stderr = conn.exec_command('webbridge restart')
time.sleep(1)
conn.close()
print_log_message('Webbridge on server: ' + mmp_address + ' restarted successfully')
except Exception as error:
print_log_message('Failed to restart webbridge on server ' + mmp_address + '. Error:')
print_log_message(str(error))
pass
def print_log_message(message):
time_stamp = datetime.datetime.now(datetime.timezone.utc)
time_stamp = str(time_stamp)
file = open('webbridge_restart_logs.txt', 'a')
file.write(time_stamp + " " + message + "\n")
file.close()
if __name__ == '__main__':
for wb in webbridges:
mmp_webbridge_restart(webbridges[wb], mmp_username, mmp_password)
################################################################
يتطلب البرنامج النصي بعض التحريرات الصغيرة (بيانات الاعتماد في السطر 29-30 وعناوين IP لجسور الويب في النشر في السطر 27) ويجب تشغيله فقط عندما لا يكون هناك حمل متوقع أو أثناء نافذة الصيانة. لا يقوم البرنامج النصي بالتحقق من جلسات العمل النشطة ويقوم ببساطة بتنفيذ الأمر 'webbridge restart' على كافة الخوادم المدرجة التي تقوم بإنهاء أي جلسة عمل WebRTC نشطة.
لأتمتة هذا البرنامج النصي، يمكن القيام بذلك من خلال إعداد مهمة cron أو على كمبيوتر Windows 10 باستخدام "مجدول المهام". بافتراض أن جهاز الكمبيوتر Win 10 قام بتثبيت Python 3. 4+، فيمكنه اتباع الخطوات التالية:
1. فتح أداة "جدولة المهام"
2. حدد 'إنشاء مهمة أساسية...'
2.1 أدخل اسما / وصفا لهذه المهمة
2.2 حدد التردد والأوقات التي تريد تشغيل هذه المهمة فيها (يوصى بأن تكون في غير أوقات الذروة، كما هو موضح هنا لكل سبت في تمام الساعة 2 صباحا)
2.3 الإجراء المطلوب تنفيذه، حدد: 'بدء برنامج'
2.4 الإجراء:
* البرنامج / البرنامج النصي: C:\<path to python.exe>
(إذا لم تكن تعرف المسار إلى python.exe، يمكن العثور عليه من خلال الانتقال إلى cmd والكتابة: python -c "إستيراد sys؛ print(sys.executable)")
* إضافة وسيطات (إختياري): WebBridge_restart.py (أو اسم البرنامج النصي python)
* ابدأ في (إختياري): C:\<path to webbridge_restart.py>
لاحظ أنه يجب أن يكون الكمبيوتر الذي يشغل وظيفة cron قادرا على الوصول إلى MMP الخاص بخوادم CMS التي تم تكوينها. بعد تشغيل البرنامج النصي، يقوم بإنشاء ملف WebBridge_restart_log.txt يحتوي على تفاصيل حول عمليات إعادة تشغيل مختلف WebBridges بالإضافة إلى أي حالات فشل محتملة. يتم عرض مثال مع اتصال واحد ناجح ب 10.48.79.194 واتصال واحد فاشل إلى 127.0.0.1 (باعتباره عنوان الاسترجاع الخاص بالكمبيوتر بالفعل).
2020-06-08 14:53:18.149915+00:00 Webbridge on server: 10.48.79.194 restarted successfully 2020-06-08 14:53:19.165543+00:00 Failed to restart webbridge on server 127.0.0.1. Error: 2020-06-08 14:53:19.165543+00:00 [Errno None] Unable to connect to port 22 on 127.0.0.1
كيف نختبر أن النص يعمل بشكل جيد؟
إذا قمت بتثبيت Python على الكمبيوتر من حيث تريد تشغيل البرنامج النصي، فيمكنك تشغيله يدويا أولا بالخطوات التالية:
- افتح cmd واستعرض إلى مكان النص التنفيذي باستخدام الأمر cd"
- قم بتشغيل ملف python باستخدام الأمر python webbridge_restart.py'
- في حالة ظهور خطأ يشير إلى عدم تثبيت وحدة "Paramico"، يلزمك تثبيت مكتبة إضافية باستخدام الأمر PIP install parico"
- وبمجرد الانتهاء، يمكنك تشغيل البرنامج النصي مرة أخرى باستخدام ملاحظة: يؤدي هذا إلى إعادة تشغيل WebBridge_restart.py" (ملاحظة: يؤدي هذا إلى إعادة تشغيل WebBridge ويتسبب في قطع اتصال إتصالات WebRTC الحالية)
إذا تم تشغيله بنجاح، فيمكنك التحقق من نتائجه في ملف webBridge_restart_logs.txt.
متى يتم التخطيط لإصلاح هذا؟
هذا ليس خطأ جديدا ولا توجد خطة لإصلاح هذا الأمر على Web Bridge 2 / CMA WebRTC. لا يتأثر تطبيق ويب Web Bridge 3 / CMS الجديد (المتوفر من الإصدار 2.9 وما بعده) بهذا الخطأ نظرا لإعادة تصميمه بالكامل. يجب على العملاء المتأثرين بشدة بهذا الأمر التفكير في الانتقال إلى تطبيق ويب CMS الجديد (على الرغم من ملاحظة أن هذا ليس تطابقا مع Web Bridge 2 في إصدار 2.9. تحقق من ملاحظات إصدار تطبيق ويب CMS 2.9 و CMS للحصول على تفاصيل كاملة حول هذا الأمر.)
معلومات ذات صلة