شكرًا على ملاحظاتك.

هذه المقالة مخصصة لفريق الدعم الفني في مؤسسة مزود الخدمة الذين يدعمون أنفسهم وعملائهم. يجب أن يكونوا على دراية باستكشاف الأخطاء وإصلاحها بشكل عام وقراءة السجلات والعمل مع حالات المشتركين.

تنقسم هذه المقالة إلى ثلاثة أقسام رئيسية:

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

ملفات سجل مفيدة

قائمة القراءة

• Webex لبوابة معارف شركاء Cisco BroadWorks
• دليل تكوين منصة XSP (R23)
• دليل إدارة برامج برودووركس (R23)
• دليل تكوين إدارة أجهزة Cisco BroadWorks (R23)
• دليل إدارة واجهة سطر الأوامر Broadworks Xsp
• وصف ميزة رمز المصادقة طويل الأمد الإصدار 23.0
• دليل تكامل مصادقة SAML، R23
• دليل خيارات دعم SSL من Cisco BroadWorks
• وصف ميزة دعم Cisco CI
• خادم دفع الإشعارات (وصف الميزة)
• دعم الإشعارات الفورية للمكالمات: وصف الميزة، الإصدار 22.0
• طريقة إجراء الاتصال (Android) بالانتقال إلى Firebase
• تخزين رموز الأجهزة الخاصة بالإشعارات الفورية من Cisco BroadWorks، الإصدار 22.0
• مخطط سعة نظام Cisco Broadworks (جدول بيانات)
• دليل أبعاد النظام الأساسي لشركة Cisco BroadWorks
• دليل هندسة أنظمة Cisco Broadworks
• متطلبات دعم مصادقة CI الإصدار 1.0 MR-7136

المشكلات والقيود المعروفة

تحتوي مقالة المشكلات والقيود المعروفة على معلومات محدثة حول المشكلات المعروفة التي حددناها في حل Webex for BroadWorks.

موصل قابلية الخدمة

تعمل خدمة Webex Serviceability على زيادة السرعة التي يمكن بها لموظفي المساعدة الفنية من Cisco تشخيص المشكلات في البنية التحتية. يقوم بأتمتة مهام البحث عن السجلات التشخيصية والمعلومات واسترجاعها وتخزينها في حالة SR. تقوم الخدمة أيضًا بتشغيل التحليل مقابل التوقيعات التشخيصية حتى تتمكن TAC من تحديد المشكلات وحلها بشكل أكثر كفاءة مع المعدات المحلية الخاصة بك.

للحصول على تفاصيل حول كيفية نشر موصل قابلية الخدمة، راجع دليل النشر لموصل Cisco Webex قابلية الخدمة.

تصعيد المشكلة

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

الإجراء

1. اجمع أكبر قدر ممكن من المعلومات من الأنظمة المتعلقة بالمشكلة.
2. اتصل بالفريق المناسب في Cisco لفتح القضية.

ما هي معلومات العميل التي يجب جمعها

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

• معرف المستخدم: عنوان البريد الإلكتروني CI أو UUID للمستخدم (هذا هو معرف Webex، ولكن إذا حصلت أيضًا على معرف BroadWorks الخاص بالمستخدم، فقم بتضمينه في تفاصيل الحالة).
• معرف المؤسسة.
• الإطار الزمني التقريبي الذي تمت خلاله مواجهة المشكلة.
• منصة العميل والإصدار.
• إرسال السجلات أو جمعها من العميل.
• سجل معرف التتبع إذا ظهر على العميل.

تحقق من تفاصيل المستخدم في مكتب المساعدة

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

الإجراء

1. قم بتسجيل الدخول إلى مكتب المساعدة.
2. ابحث عن المستخدم ثم انقر عليه. يؤدي هذا إلى فتح شاشة ملخص المستخدم.
3. انقر فوق اسم المستخدم لرؤية التكوين التفصيلي للمستخدم. تتضمن المعلومات المفيدة في طريقة العرض هذه UUID للمستخدم ومجموعة الهوية المشتركة (CI) ومجموعة تطبيقات Webex وسلوك الاتصال ومعرف GUID لحساب BroadWorks
4. انقر فوق النسخ إذا كنت تريد استخدام هذه المعلومات في أداة أخرى، أو إرفاقها بعلبة Cisco.

عرض مؤسسة العميل في مكتب المساعدة

يمكن لمسؤولي الشركاء الذين لديهم امتيازات دور مسؤول مكتب المساعدة (أساسي أو متقدم) استخدام هذا الإجراء لعرض تفاصيل مؤسسة العميل في طريقة عرض مكتب المساعدة.

الإجراء

1. قم بتسجيل الدخول إلى مكتب المساعدة.
2. ابحث عن اسم مؤسسة العميل ثم انقر عليه.
3. قم بالتمرير لأسفل حتى ترى عرض بوابة العملاء وانقر فوق عرض اسم العميل لمشاهدة عرض للقراءة فقط لمؤسسة العميل - بما في ذلك المستخدمين والتكوين.

استرجع سجلات المستخدم من Partner Hub

عند استكشاف مشكلات سطح المكتب وعميل الهاتف المحمول وإصلاحها، من المهم أن يتمكن الشركاء (و TAC) من عرض سجلات العميل.

الإجراء

1. اطلب من المستخدم إرسال السجلات. للحصول على المساعدة، راجع: تطبيق Webex | الإبلاغ عن مشكلة.
2. اطلب من المستخدم تصدير بيئة الاتصال وإرسال ملف ced.dat إليك.
3. احصل على سجلات العميل من Partner Hub أو مكتب المساعدة.

   خيار مركز الشركاء:

   1. قم بتسجيل الدخول إلى Partner Hub وابحث عن منظمة العملاء الخاصة بالمستخدم.
   2. حدد استكشاف الأخطاء وإصلاحها.
   3. حدد السجلات.
   4. ابحث عن المستخدم (عن طريق البريد الإلكتروني).
   5. عرض سجلات العميل وتنزيلها كملف مضغوط.

   خيار مكتب المساعدة:

   1. قم بتسجيل الدخول إلى مكتب المساعدة.
   2. ابحث عن المنظمة.
   3. انقر فوق المؤسسة (تفتح شاشة الملخص).
   4. قم بالتمرير لأسفل للنقر فوق عرض العميل.
   5. حدد استكشاف الأخطاء وإصلاحها.
   6. حدد السجلات.
   7. ابحث عن المستخدم (عن طريق البريد الإلكتروني).
   8. عرض سجلات العميل وتنزيلها كملف مضغوط.

كيفية العثور على إصدار العميل

الإجراء

1. شارك هذا الرابط مع المستخدم: https://help.webex.com/njpf8r5
2. اطلب من المستخدم أن يرسل لك رقم الإصدار.

فحص العميل لخدمة الاتصال

الإجراء

1. قم بتسجيل الدخول إلى عميل Webex.
2. تحقق من وجود رمز خيارات الاتصال (هاتف مزود بعتاد فوقه) على الشريط الجانبي. إذا لم يكن الرمز موجودًا، فقد لا يتم تمكين المستخدم بعد لخدمة الاتصال في Control Hub.
3. افتح قائمة الإعدادات/التفضيلات وانتقل إلى قسم خدمات الهاتف. يجب أن تشاهد حالة جلسة SSO التي قمت بتسجيل الدخول إليها. (في حالة عرض خدمة هاتف مختلفة، مثلWebex Calling، فإن المستخدم لا يستخدم Webex لـ Cisco BroadWorks.)

   هذا التحقق يعني:

   • نجح العميل في اجتياز خدمات Webex المصغرة المطلوبة.
   • تمت المصادقة بنجاح من قبل المستخدم.
   • يتم إصدار رمز ويب JSON طويل الأمد للعميل بواسطة نظام BroadWorks الخاص بك.
   • استعاد العميل ملف تعريف الجهاز الخاص به وقام بالتسجيل في BroadWorks.

احصل على سجلات العملاء أو التعليقات

• راجع قسم الموارد للعثور على سجلات عملاء محددة على عملاء Webex لسطح المكتب، أو اطلب من المستخدمين إرسال السجلات. للحصول على المساعدة، راجع: تطبيق Webex | الإبلاغ عن مشكلة.
• اطلب من مستخدمي عملاء الأجهزة المحمولة إرسال السجلات، ثم يمكنك الحصول عليها من خلال Partner Hub أو Help Desk.
  إرسال السجلات صامت. ومع ذلك، إذا أرسل المستخدم تعليقات، فسيتم نقلها إلى فريق مطوري Webex App. تأكد من تسجيل رقم ملاحظات المستخدم إذا كنت تريد المتابعة مع Cisco. على سبيل المثال:

  

احصل على بيانات بيئة الاتصال

يتم تنقيح سجلات عملاء Webex بشكل كبير لإزالة معلومات التعريف الشخصية. يجب عليك تصدير بيانات بيئة الاتصال من العميل في نفس الجلسة التي لاحظت فيها المشكلة.

الإجراء

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

تحقق من أنه يجب على Webex التسجيل في BroadWorks

يتحقق تطبيق Webex من المعلومات التالية لتحديد ما إذا كان سيتم التسجيل في BroadWorks أم لا:

• استحقاق المستخدم لموصل البرودوركس.
• سلوك الاتصال للمؤسسة والمستخدم.

تحقق من سلوك الاتصال الخاص بالمستخدم واستحقاق الموصل

1. قم بتسجيل الدخول إلى Help Desk باستخدام بيانات اعتماد مسؤول الشريك.
2. ابحث عن المستخدم.
3. انقر فوق المستخدم وتحقق من إدخال سلوك الاتصال. يجب أن يكون «الاتصال بـ Webex».

   

4. انقر فوق اسم المستخدم لفتح شاشة تفاصيل المستخدم.
5. قم بالتمرير لأسفل لتحديد موقع قسم الاستحقاقات، وتحقق من تضمين موصل broadworks

   

   يجب ألا يتمتع مستخدم Webex لـ Cisco BroadWorks بالاستحقاق القياسي لـ bc-sp-standard إذا كان ينوي استخدام Webex لـ Cisco BroadWorks. هذا هو استحقاق «Webex Calling(Broadcloud)» وهو تطبيق Webex للاتصال من خلال خدمة الاتصال السحابية التي تديرها Cisco.

تحقق من سلوك الاتصال الخاص بالمؤسسة

1. قم بتسجيل الدخول إلى Help Desk باستخدام بيانات اعتماد مسؤول الشريك.
2. ابحث عن المنظمة.
3. انقر فوق المؤسسة وتحقق من إدخال سلوك الاتصال. يجب أن يكون «الاتصال بـ Webex».

تحليل PSLog لمشكلات توفير المستخدم

استخدم PSLog الخاص بخادم التطبيقات لرؤية طلب HTTP POST إلى جسر التوفير والاستجابة من Webex. في حالة العمل الصحيحة، تكون الاستجابة 200 موافق وبعد بضع دقائق يمكنك رؤية المستخدم - ومؤسسة العملاء الجديدة إذا كانت أول مستخدم - تم إنشاؤها في Webex. يمكنك التحقق من ذلك من خلال البحث في مكتب المساعدة عن عنوان البريد الإلكتروني الذي تراه في POST.

قبل أن تبدأ

قم بتجميع PSLog من خادم التطبيقات أثناء محاولة توفير التدفق مع مستخدم اختبار.

الإجراء

1. أولاً، تحقق من رمز استجابة HTTP:
   • أي شيء بخلاف 200 OK هو فشل في توفير المستخدم.
   • 200 OK لا يزال من الممكن أن يشير إلى الفشل إذا لم يعمل شيء ما يتعلق بملف تعريف المشترك في خدمات Webex في الجزء العلوي من جسر التوفير.
   • قد يحتوي 400 على عقدة رسالة في الاستجابة. لم يتمكن جسر التوفير من معالجة شيء ما في SubscriberProfile. قد يكون هناك خطأ في تفاصيل المشترك، أو عدم التوافق مع إعداد في النموذج.
   • 401 يعني أن بيانات اعتماد التوفير التي تم إدخالها على AS لا تتطابق مع تلك التي تم إدخالها في النموذج في Partner Hub.
   • قد يشير 403 إلى شيء تم تكوينه بشكل خاطئ على خادم التطبيقات. تحقق من هدف الطلب. يجب ألا يكون عنوان IP، بل يجب أن يكون عنوان URL لجسر التوفير الذي يمكنك رؤيته في القالب الخاص بك في Partner Hub.
   • يشير 409 إلى وجود تعارض بين ملف تعريف المشترك المقدم وبيانات Webex الحالية. قد يكون هناك مستخدم موجود بعنوان البريد الإلكتروني هذا. تحقق من الرسالة في الاستجابة.
2. يمكنك أيضًا التحقق من HTTP POST الأصلي بحثًا عن أي قيم مشبوهة قد تتسبب في فشل التوفير. يحتوي POST على بنية XML لملف تعريف المشترك. داخل هذا، العقد المفيدة التي يجب التحقق منها هي:
   • bwuserid: استخدم هذا للعثور على ملف تعريف المشترك إذا كنت بحاجة إلى تحريره في BroadWorks.
   • المجموعة: إذا كان النموذج في «وضع موفر الخدمة»، فسيتم كتابة هذا الحرف بأحرف صغيرة ويصبح اسم مؤسسة العميل التي تراها في Partner Hub.
   • ServiceProvider: إذا كان القالب في «وضع المؤسسة»، فسيتم كتابة هذا بأحرف صغيرة ويصبح اسم مؤسسة العميل التي تراها في Partner Hub.
   • رقم الهاتف الأساسي: يجب أن يكون موجودًا. يفشل التوفير بدونه.
   • البريد الإلكتروني: يصبح معرف المستخدم في Webex. يجب أن يكون صالحًا وفريدًا لـ Webex، وإلا يفشل التوفير.

     تجاهل مقطع الخدمات: تم إنشاؤه بواسطة AS، وتم قبوله ولكن لا يستخدمه Webex.

تحليل سجلات XSP لاستكشاف أخطاء تسجيل دخول المشترك وإصلاحها

يصف هذا التدفق وضع مصادقة BroadWorks. يمكنك رؤية وضع المصادقة على قالب BroadWorks، في Partner Hub. راجع تكوين قوالب العملاء الخاصة بك في https://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726.

يوضح مخطط السلم التالي التفاعل بين المستخدم والعميل وخدمات Webex ونظام BroadWorks، عندما يقوم المستخدم بمصادقة BroadWorks في تطبيق Webex. أيضًا، يتم تأمين الاتصال بين Webex و XSP بواسطة MTLS.

توضح المناقشة التالية ما يمكن أن تتوقع رؤيته عند التحقق من السجلات لتسجيل دخول ناجح.

يتفاعل المستخدم مع العميل، ويتفاعل العميل مع خدمات Webex:

• يقدم المستخدم عنوان بريده الإلكتروني إلى تطبيق Webex (1 في الرسم التخطيطي).
• يعرف CI إعادة توجيه هذا المستخدم لإدخال كلمة مرور BroadWorks (عبر UAP) (2 في الرسم التخطيطي).
• يقوم وكيل IDP بإرسال طلب الحصول على ملف تعريف إلى واجهة Xsi على XSP.

في سجل الوصول إلى tomcat:

• ابحث عن طلب GET لملف تعريف المشترك، من Webex إلى واجهة Xsi-Actions (2.1 في الرسم التخطيطي). يحتوي على معرف مستخدم Webex. على سبيل المثال:

  احصل على /com.broadsoft.xsi-actions/v2.0/المستخدم/ webexuserid@example.com /الملف الشخصي

في سجل الإجراءات XSIA:

• ابحث عن طلب GET للملف الشخصي من Webex (2.1 في الرسم التخطيطي). يحتوي على معرف مستخدم Webex. على سبيل المثال:

  GET /com.broadsoft.xsi-actions/v2.0/user/ webexuserid@example.com /الملف الشخصي تتضمن العناوين التفويض: الأساسي ووكيل المستخدم: BroadworkSteamsClient

• يقوم XSP بعد ذلك بمصادقة OCI-P الأساسية مقابل BroadWorks (المصادقة والتحقق من الطلب والمصادقة، مثل أي تطبيق آخر يقوم بالمصادقة الأساسية عبر Xsi) وأيضًا UsergetRequest و ServiceProviderGetRequest لجمع معلومات المشترك.
• تحتوي استجابة Xsi لـ Webex على كتلة ملف تعريف XML تحتوي على معرف المستخدم (BroadWorks) وتفاصيل أخرى (2.2 في الرسم التخطيطي).

تفاعلات العميل وخدمات Webex:

• يطابق بروكسي IDP ملف تعريف المستخدم المستلم من BroadWorks ويصدر تأكيد SAML للعميل (2.3 في الرسم التخطيطي).
• يتبادل العميل تأكيد SAML مقابل رمز CI (3 في الرسم التخطيطي).
• يتحقق العميل من أن المستخدم الذي قام بتسجيل الدخول لديه استحقاق موصل broadworks (4 في الرسم التخطيطي). يمكنك التحقق من استحقاقات المستخدم في مكتب المساعدة.
• يستخدم العميل رمز CI لطلب رمز ويب JSON (JWT) من وكيل IDP (5 في الرسم التخطيطي).
• يقوم وكيل IDP بالتحقق من صحة رمز CI في CI.
• يطلب وكيل IDP JWT من خدمة المصادقة.

في سجل خدمة المصادقة:

• ابحث عن طلب الرمز المميز من Webex (5.2 في الرسم التخطيطي)، على سبيل المثال: GET /authservice/Token الذي يحتوي على عنوان http_bw_userid وغيرها.
• يقوم XSP بعمل OCI-P UserGetLoginInfoRequest، للتحقق من أن معرف المستخدم المقدم يتوافق مع مستخدم BroadWorks (5.3 في الرسم التخطيطي). أنشأت AuthService الثقة مع Webex بفضل اتصال MTLS، لذلك يمكن إصدار LLT.
• ابحث عن الاستجابة (5.4 في الرسم التخطيطي) من LongLivedTokenManager - تم إنشاء الرمز المميز، الموضوع: bwksUserId@example.com، المُصدر: BroadWorks... و statusCode=200 الذي يمكنك ربطه بالطلب الأصلي باستخدام عنوان trackingid: CLIENT...

في سجل الإجراءات XSIA:

• يمكن للعميل تقديم الرمز المميز طويل الأجل في واجهة Xsi-Actions للحصول على ملف تعريف الجهاز الخاص به (6 في الرسم التخطيطي). على سبيل المثال: GET /com.broadsoft.xsi-actions/v2.0/user/bwksuserID %40example.com/profile/device مع إذن العنوان: الرمز المميز للحامل ووكيل المستخدم: WebExTeams (المتغير/الإصدار)
• تقوم واجهة Xsi-Actions بنشر الرمز المميز إلى خدمة المصادقة (التي تمت تهيئتها لتكون على واجهة الاسترجاع) على سبيل المثال: 127.0.0. 1:80 POST http://127.0.0.1:80/authService/token والتي يمكنك ربطها بمعرف التتبع: العميل... في عنوان GET وعنوان X-BROADSOFT-CORRELATION-ID: CLIENT... في المنشور.

في سجل خدمة المصادقة:

• استلام البريد من Xsi (الاسترجاع)

• رمز الحالة = 200 عودة إلى Xsi

• واستجابة للتحقق من صحة الرمز المميز، مع وجود كتلة JSON "رمزية" في الجسم.

• مرتبط باستخدام معرف التتبع: CLIENT...

في سجل الإجراءات XSIA:

• بعد تلقي 200 موافقة من خدمة المصادقة، التي تحققت من صحة الرمز المميز للعميل، يرسل تطبيق Xsi-Actions الآن طلب OCI-P للمستخدم الأساسي وطلب SCADeviceGetList
• يتلقى استجابة GetList الأساسية لمستخدم OCI-P وجهاز SCA التي تحتوي على بنية XML الخاصة بـ جدول جهاز الوصول.
• يتم ترميز استجابة OCI-P كاستجابة Xsi للعميل، بما في ذلك بنية AccessDevices XML، التي تحتوي على DeviceTypes. على سبيل المثال: Business Communicator - الكمبيوتر الشخصي وعناوين URL حيث يمكن للعميل استرداد ملفات تكوين الجهاز.

يستمر العميل كالمعتاد:

• يحدد إدخال الجهاز ويتفاعل مع DMS للحصول على ملف تعريف الجهاز (6 في الرسم التخطيطي).
• تم استرداد التسجيلات إلى BroadWorks عبر SBC في التكوين من DMS (7 في الرسم التخطيطي).

مشكلات مركز الشركاء

1. لا يمكن للمسؤول رؤية مؤسسات العملاء

بصفتك مسؤولًا عن مؤسستك الشريكة في Webex، يجب أن يكون لديك دور المسؤول الكامل. يتم استخدام هذا الدور لإدارة المؤسسة الشريكة، بما في ذلك تعيين الامتيازات الإدارية لنفسك وللآخرين. لإدارة منظمات العملاء، تحتاج إلى منح نفسك (أو أشخاص آخرين) دور مسؤول المبيعات الكامل أو دور مسؤول المبيعات. للحصول على التفاصيل، راجع تعيين أدوار حساب المؤسسة في Control Hub.

مشكلات توفير المستخدم

1. أخطاء IM&P المتكاملة لمؤسسات/عملاء محددين

إذا كان لديك مزيج من المؤسسات التي تستخدم خدمات تعاون سحابية مختلفة، على سبيل المثال، UC-one SaaS وWebex لـ Cisco BroadWorks، فربما تكون قد اخترت تعديل محول التزويد على أساس كل مؤسسة.

للتحقق مما تم تكوينه لـ IM&P المتكامل (الإعداد الافتراضي للمؤسسات، ما لم يكن هناك إعداد أكثر تحديدًا)، قم بتشغيل AS_CLI/interface/Messaging> get. بالنسبة لمعلمات التزويد الخاصة بمؤسسة معينة، افتح المؤسسة وانتقل إلى الخدمات > IM&P المتكاملة.

تحقق من أن تكوين IM&P المتكامل لتلك المؤسسة يطابق تمامًا ما يظهر في نموذج العميل في Partner Hub. يجب أن تتطابق الإعدادات التالية، وإلا يفشل التوفير لجميع المستخدمين في المؤسسة:

2. أخطاء IM&P المتكاملة لمستخدمين محددين

ينطبق هذا إذا كنت تستخدم توفير التدفق، ويفترض أن التوفير يعمل لبعض/معظم المستخدمين (حتى تتمكن من استبعاد مشكلة التكوين). إذا كنت ترى أخطاء IM&P المدمجة في BroadWorks، على سبيل المثال، «[Error 18215] خطأ التزويد مع خادم المراسلة» و «[Error 18211] خطأ الاتصال بخادم المراسلة»، يجب التحقق من الأسباب المحتملة التالية:

• يمكن أن يكون عنوان البريد الإلكتروني للمستخدم موجودًا بالفعل CI. ابحث عن المستخدم في مكتب المساعدة للتحقق مما إذا كان عنوان بريده الإلكتروني موجودًا بالفعل. هذا ليس بالضرورة قاطعًا، لأن المستخدم قد يكون موجودًا في مؤسسة لا يُسمح لك برؤية بياناتها في مكتب المساعدة.
• قام المستخدم بالتسجيل بشكل مستقل في Webex، قبل أن يتم تعيين خدمة IM&P المتكاملة. في هذه الحالة، يتمثل أحد الخيارات في جعل المستخدم يحذف حساباته المجانية بحيث يمكن أن تصبح جزءًا من منظمة العملاء التي تقوم بتوفيرها. التعليمات موجودة على https://help.webex.com/5m4i4y
• ليس لدى المستخدم رقم هاتف أساسي مخصص لملف التعريف الخاص به (يجب أن يكون لدى جميع مشتركي Webex لـ Cisco BroadWorks DID أساسي). راجع موضوع تحليل PSLog من AS.

3. حالات فشل تزويد المستخدم في الاستجابة من جسر التوفير

في حالة عدم ظهور المستخدمين في Control Hub، في غضون بضع دقائق من تعيين IM&P المدمجين، ألق نظرة على رموز الاستجابة من خدمة جسر التوفير. قم بتشغيل PSLog لإلقاء نظرة على رموز استجابة HTTP.

200 OK

لا تعني استجابة 200 OK أن المستخدم قد تم توفيره بنجاح. هذا يعني أن خدمة التزويد تلقت الطلب وأرسلت بنجاح طلب إنشاء المستخدم المقابل إلى خدمات المنبع. معاملة التوفير غير متزامنة حسب التصميم. تستجيب الخدمة 200 OK لأن عملية إنشاء المستخدم يمكن أن تستغرق عدة دقائق، ولأسباب تتعلق بالأداء، لا نريد تلقي طلبات متعددة لإنشاء نفس المستخدم. ومع ذلك، إذا لم يظهر المستخدم في النهاية في مؤسسة العميل بعد استجابة 200 OK، فقد يشير ذلك إلى فشل إنشاء المستخدم في خدمات Webex في بداية خدمة التوفير. تحتاج إلى تصعيد فشل التوفير الذي يحتوي على استجابة 200 OK.

400 طلب غير صالح

تحقق من استجابة HTTP التي يجب أن تحتوي على مزيد من التفاصيل حول المشكلات المحتملة التي قد تسبب هذه الاستجابة من خدمة التوفير. بعض الأمثلة على العقدة:

• «لا يمكن الوثوق بالبريد الإلكتروني لـ BroadWorks مع واجهة برمجة تطبيقات التوفير القديمة.» عنوان البريد الإلكتروني المرتبط بطلب توفير المستخدم الفاشل غير صالح، أو تمت كتابته بشكل خاطئ، ولكنك أكدت في النموذج أنه يمكن الوثوق بعناوين البريد الإلكتروني. تحقق من ملفات تعريف المستخدمين في BroadWorks، وتحديدًا معرف البريد الإلكتروني.
• لم يتم العثور على مؤسسة العميل في قاعدة البيانات وأيضًا لم يتم تمكين علامة إنشاء المؤسسة الجديدة.» يجب أن يؤدي طلب التوفير الفاشل هذا إلى إنشاء مؤسسة عملاء جديدة في Webex، ولكن تم تكوين القالب الخاص بك لمنع إنشاء منظمات عملاء جديدة. إذا كنت ترغب في السماح للمؤسسات الجديدة، بالنسبة لنطاقات البريد الإلكتروني التي لا تتطابق مع العملاء الحاليين في Webex، فيمكنك إعادة تكوين القالب الخاص بك في Partner Hub وإعادة اختبار طلب التوفير. ومع ذلك، إذا كنت لا تتوقع إنشاء مؤسسة جديدة لهذا المستخدم، فربما يكون عنوان البريد الإلكتروني مكتوبًا بشكل خاطئ (تحديدًا جزء المجال). تحقق من معرف البريد الإلكتروني للمستخدم في BroadWorks.

403 ممنوع

لا يمكن أن ينجح طلب التوفير حتى تقوم بإصلاح التكوين. ستحتاج إلى التحقق من الطلب والاستجابة في هذه الحالة. على سبيل المثال، إذا رأيت عنوان IP كهدف لطلب التوفير - بدلاً من عنوان URL لجسر التوفير المناسب لمؤسستك (راجع موضوعات تكوين جدار الحماية في دليل الحلول) - فقد يشير ذلك إلى أن خادم التطبيقات يفتقد التصحيح المطلوب (ap373197).

تحقق من تطبيق جميع التصحيحات المطلوبة على خادم التطبيقات، ومن أنك أكملت التكوين ذي الصلة لتوفير التدفق الناجح.

409 الصراع

لا يمكن متابعة طلب التوفير نظرًا لوجود مستخدم موجود في Webex يطابق عنوان البريد الإلكتروني في الطلب.

4. المستخدم موجود بالفعل في CI

احصل على البريد الإلكتروني للمشترك من طلب HTTP POST وابحث عنه في مكتب المساعدة. قد لا ترى المستخدم إذا لم يُسمح لك بذلك، ولكن قد ترى أيضًا أن المستخدم موجود في مؤسسة «مجانية» على سبيل المثال «المستهلك». يمكنك أن تطلب من هذا المستخدم حذف حسابه المجاني، أو يمكنك استخدام عنوان بريد إلكتروني مختلف لتوفيره. راجع https://help.webex.com/ndta402.

مشكلات تسجيل دخول المستخدم

1. لا يتم تحميل بوابة تنشيط المستخدم

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

2. فشل تسجيل الدخول الأحادي

• في BroadWorks، تحقق من تعيين أنواع الأجهزة للمستخدم لتطبيق Webex (راجع قسم ملفات تعريف الأجهزة في قسم إعداد البيئة في دليل الحلول).
• تحقق من أن المستخدم يستخدم كلمة المرور الصحيحة. إذا تم تكوين القالب الذي استخدمته لتوفير مؤسسة العميل الخاصة بالمستخدم (في Partner Hub) لمصادقة BroadWorks، فيجب أن يقوم المستخدم بإدخال كلمة مرور BroadWorks «Web Access» الخاصة به. قد يحتاج المستخدم أيضًا إلى إدخال معرف مستخدم BroadWorks الخاص به إذا لم يتم تكوين عنوان بريده الإلكتروني كمعرف مستخدم بديل. تأكد من أن المستخدم قد أدخل الأحرف الكبيرة والصغيرة بشكل صحيح.

مشكلات تكوين الاتصال والتسجيل

بعد توفير مستخدم في Webex وتسجيل الدخول بنجاح إلى تطبيق Webex، يقوم التطبيق بالتسجيل في BroadWorks. فيما يلي تسلسل التسجيل المتوقع والعلامات الناتجة عن التسجيل الصحي (كما يظهر من تطبيق Webex):

1. تسلسل التسجيل المتوقع

1. يتصل العميل بـ XSI للحصول على رمز إدارة الجهاز وعنوان URL لـ DMS.
2. يطلب العميل ملف تعريف الجهاز الخاص به من DMS من خلال تقديم الرمز المميز من الخطوة 1.
3. يقوم العميل بقراءة ملف تعريف الجهاز واسترداد بيانات اعتماد SIP والعناوين والمنافذ.
4. يرسل العميل سجل SIP إلى SBC باستخدام المعلومات من الخطوة 3.
5. ترسل SBC سجل SIP إلى AS (قد تقوم SBC بإجراء بحث في NS لتحديد موقع AS إذا لم تكن SBC تعرف مستخدم SIP بالفعل.).

2. العلامات المتوقعة لتسجيل العميل الناجح

تظهر أيقونة خيارات الاتصال في واجهة Webex.

في علامة تبويب خدمات الهاتف لتطبيق Webex (مثل الإعدادات > خدمات الهاتف على Windows والتفضيلات > خدمات الهاتف على Mac)، تعني الرسالة «جلسة SSO: لقد قمت بتسجيل الدخول» أن التطبيق تم تسجيله بنجاح (إلى BroadWorks في هذه الحالة).

3. لا يوجد لدى العميل رمز الاتصال

يعني هذا في معظم الأحيان أن المستخدم ليس لديه الترخيص/الاستحقاقات الصحيحة.

هذا تسجيل غير ناجح. هناك عدة أسباب لفشل عميل Webex App في التسجيل في BroadWorks:

4. يتم اختبار خدمات الاتصال المتعددة مع نفس العملاء

يمكن أن تحدث هذه المشكلة المعروفة بسبب تغيير العميل بين جهات الاتصال الخلفية المختلفة. من المرجح أن يحدث ذلك أثناء تجارب خدمات الاتصال المختلفة المقدمة عبر (نفس) عملاء Webex App. يمكنك إعادة تعيين قاعدة بيانات العميل (الرابط) لمعالجة هذه المشكلة.

5. التكوين الخاطئ لخدمة المصادقة

تحقق من XSP (مقدمي الخدمات) الذين يستضيفون خدمة المصادقة مقابل دليل الحلول (راجع تكوين الخدمات على Webex لـ Cisco BroadWorks XSPs). على وجه التحديد:

• يتم نسخ مفاتيح RSA (التي تقوم بإنشائها على XSP واحد) على جميع XSPs
• تم توفير عنوان URL لخدمة المصادقة إلى حاوية الويب على جميع XSPs، وتم إدخاله بشكل صحيح في المجموعة في Partner Hub
• تم تكوين المصادقة الخارجية بواسطة الشهادات:

  XSP_CLI/النظام/أداة الاتصالات/الإعدادات الافتراضية/المصادقة الخارجية/مصادقة الشهادة> احصل على

  allowUserApp = false

  allowClientApp = true

• عند استخدام MTLS، يجب تحميل شهادة عميل Webex إلى XSPs (يمكنك الحصول على الشهادة من Partner Hub، في صفحة إعدادات BroadWorks).

6. التكوين الخاطئ لعلامات BroadWorks

تحقق من تكوين علامات BroadWorks المطلوبة لتطبيق Webex. راجع دليل تكوين Webex لـ Cisco BroadWorks للحصول على معلومات حول علامات التكوين. تأكد من عدم وجود تعارضات أو قيم غير صحيحة. على وجه التحديد، يجب أن تكون علامة %SBC_ADDRESS_WXT% هي SBC تجاه مسجل SIP الخاص بك لعملاء تطبيق Webex.

7. يقوم عميل سطح المكتب بفصل خدمات الهاتف بعد اتصال SSO الناجح

يمكن أن تحدث هذه المشكلة بسبب قيام نفس المستخدم بتسجيل الدخول إلى عدة عملاء على نفس نوع النظام الأساسي. على سبيل المثال، إذا قام المستخدم بتسجيل الدخول بنجاح إلى تطبيق Webex على Windows، ثم قام بتسجيل الدخول إلى تطبيق Webex على جهاز Windows مختلف، فهناك جلسة SSO نشطة فقط على أحد الأجهزة. هذا حسب التصميم. إذا كنت بحاجة ماسة إلى حل هذه المشكلة، فيمكنك تكوين BroadWorks للحصول على مثيلات متعددة من نفس نوع الجهاز، ولكن يجب أن تحتوي على عناوين SIP فريدة. يقع هذا التكوين خارج نطاق Webex لـ Cisco BroadWorks.

8. جهاز سطح المكتب غير متوفر للمستخدم

يظهر هذا التوقيع في سجل العميل:

[0x70000476b000] أداة تنزيل تكوين برودوركس.cpp:106 <Error>

نجح تشغيل قائمة أجهزة Access: BWC: SCF: Config: تنزيل ملف تعريف الجهاز «Business Communicator - الكمبيوتر الشخصي» غير موجود.

9. ترن مكالمات الهاتف المحمول الواردة مرة واحدة أو لا يمكن الرد عليها

يتم رنين المكالمات الواردة إلى Webex mobile مرة واحدة فقط، أو لا يمكن للمستخدم الرد على المكالمة الواردة. قد تستمر نقاط النهاية الأخرى لنفس المستخدم في الرنين.

كيفية التعرف؟

في سجلات عميل Webex للأجهزة المحمولة، ابحث عن رمز خطأ XSI 101002 في تدفق المكالمات الفورية. على سبيل المثال:

رمز الاستجابة: 400

<callID>فشل معلومات HandlePushCall:BWC: داخلي: مكالمة دفع: حالة xsi لمعرف الاتصال: رمز خطأ xsi: 101002

<callID>إغلاق المكالمة الفورية بالسبب: BWC: داخلي: حاول إغلاق المكالمة الفورية باستخدام id =، السبب = callAbandoned

السبب: يمكن أن يشير رمز الخطأ 101002 إلى أن خادم التطبيق الخاطئ (AS) قد تم إرجاعه في استجابة LocateUser. يمكن أن يحدث هذا عندما ينتقل المستخدم إلى AS ثانوي.

الفحوصات الموصى بها:

من ADP أو XSP حيث يتم نشر Push، قم بتشغيل LocateUser للمستخدم المتأثر:

<FQDN or IP address of NS Server>curl 'http: //:80/سيرفلت/تحديد موقع المستخدم؟ <BW userID @domain >عنوان URL = والإرجاع المتوافق xsp=true&callprequest = true'

مثال: curl 'http://1.1.1.1:80/servlet/LocateUser؟ عنوان url = 9721112222@gmail.com & الإرجاع المتوافق XSP = «صحيح» و «طلب الاتصال المسبق = صحيح»

الحل: إذا قام LocateUser بإرجاع AS الثانوي للمستخدم، فقم بتشغيل البرنامج النصي MigrateUserToDefaultNode.pl على خادم NS الأساسي لترحيل المستخدمين مرة أخرى إلى خادم التطبيقات الأساسي للمجموعة.

قم بتسجيل الدخول إلى خادم NS من خلال SSH، وانتقل إلى دليل /usr/local/broadworks/bw_base/bin، وقم بتشغيل: MigrateUserToDefaultNode.pl <hostingNE>

مثال: ترحيل المستخدم إلى node.pl bwas1 الافتراضي

للحصول على قيمة HostingNE، قم بتشغيل: NS_CLI/النظام/الجهاز/الاستضافة> get

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

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

لا يمكن تشغيل البرنامج النصي لمستخدم واحد فقط. يقوم بترحيل جميع المستخدمين المدرجين في إخراج LocateUser. إذا لم تتمكن من تشغيل البرنامج النصي، فقم بحذف المستخدم المتأثر وإعادة إنشائه في BroadWorks بحيث تتم إعادة بناء المستخدم على AS الصحيح.

يمكن أن تتسبب أي رسالة SIP من جهاز المستخدم إلى AS الثانوي في ترحيل المستخدم. عادةً ما يتراجع المستخدمون إلى AS الأساسي بعد الفاصل الزمني الافتراضي البالغ 15 دقيقة ما لم تستمر الطلبات الواردة في الوصول إلى AS الثانوي. على سبيل المثال، إذا لم يتمكن SBC من الاتصال بـ AS1 وتكرر إلى AS الثانوي، فقد ينتقل المستخدمون المتأثرون إلى AS الثانوي. واعتمادًا على عملية النشر، يمكن أن تظل مجموعة قنوات اتصال واحدة أو مستخدم مثبتًا على AS الثانوي إذا استمر SBC في مواجهة مشكلات في الوصول إلى AS الأساسي.

لمزيد من المعلومات، راجع المستندات التالية:

• الأقسام 3.4.5 إمكانية التراجع لمستخدم خادم التطبيقات و5.4.5 التراجع التلقائي في دليل التكرار الخاص بـ Cisco BroadWorks

• وصف ميزة تحسينات Cisco BroadWorks ASR

9. تم قطع خدمات الهاتف

إذا ظهرت خدمات الهاتف على أنها غير متصلة بعد تسجيل دخول المستخدم إلى تطبيق Webex، أو إذا انقطعت خدمات الهاتف أثناء استخدام المستخدم للعميل، فتحقق من نوع العميل وتدفق التسجيل.

بالنسبة لعملاء Windows و Mac، يسجل تطبيق Webex لـ SIP ويحتفظ بتسجيل SIP نشط أثناء تسجيل دخول المستخدم.

تحقق مما يلي:

1. تحقق من تنزيل config-wxt.xml بنجاح.

في سجلات العميل، ابحث عن ConfigDownload.

يظهر التنزيل الناجح:

ConfigDownload - اكتمل بنجاح

إذا أظهرت السجلات الخطأ التالي، فتحقق من سجلات AuthService بحثًا عن الأخطاء المتعلقة بالرمز المميز:

ConfigDownload - فشل مع رمز الخطأ: 1511

2. تحقق من العثور على ملف تعريف جهاز Webex.

في سجلات العميل، تأكد من العثور على جهاز الوصول وأن used_value هو 1. إذا كان used_value يساوي 0، تحقق مما إذا كان الخط الأساسي ممكّنًا أو معطلاً وتحقق من قيمة العلامة. لمزيد من التفاصيل، راجع القسم 6.1.44 ملف التعريف الأساسي في دليل تكوين Webex for BroadWorks.

أمثلة لإدخالات السجل:

:BWC:SCF: التكوين/التنزيل - تم العثور على جهاز الوصول

:BWC:SCF: تكوين التنزيل - جهاز الوصول: نوع الجهاز = اتصال الأعمال - الكمبيوتر الشخصي، مستوى الجهاز = المجموعة، السماح بالإنهاء = 1، هو مالك الجهاز [has_value: 0، used_value: 1]، Haskowerالجهاز: 1، نوع نقطة النهاية: مظهر المكالمة المشتركة

: BWC: SCF: تكوين التنزيل - جهاز الوصول: نوع الجهاز = الاتصال - الهاتف المحمول، مستوى الجهاز = المجموعة، السماح بالإنهاء = 1، هو مالك الجهاز [has_value: 0، used_value: 1]، لديه جهاز المالك: 1، نوع نقطة النهاية: مظهر المكالمة المشتركة

: BWC: SCF: تكوين التنزيل - جهاز الوصول: نوع الجهاز = الاتصال - الجهاز اللوحي، مستوى الجهاز = المجموعة، السماح بالإنهاء = 1، هو مالك الجهاز [has_value: 0، use_value: 1]، لديه جهاز المالك: 1، نوع نقطة النهاية: مظهر المكالمة المشتركة

3. تحقق من فشل DNS عند حل عنوان وكيل SIP.

للحصول على تفاصيل حول اكتشاف بروكسي SIP، راجع القسم 6.1.6 اكتشاف وكيل SIP الديناميكي في دليل تكوين Webex for BroadWorks.

يُظهر اكتشاف البروكسي الناجح:

تم الانتهاء من اكتشاف البروكسي، وحصلت على <number>نتائج

4. تحقق مما إذا كان تسجيل SIP فاشلاً.

إذا كانت السجلات تعرض mRegistration: TCPtimeout أو السبب: SIP; cause=200; text= last=TCP-timeout»، فلن يتمكن عميل Webex من إنشاء اتصال TCP منخفض المستوى إلى SBC. لا يكتمل تسجيل SIP عند حدوث هذا الخطأ. تحقق مما إذا كان TCP محظورًا على شبكة المستخدم، أو ما إذا كان SBC يرفض اتصال TCP.

إذا تم رفض طلب SIP REGISTER أو لم يتلق ردًا، فابحث في السجلات عن REGISTER sip وتحقق من إرجاع SIP/2.0 200 OK. إذا لم يتم إرجاعها، تحقق مما إذا كانت شبكة المستخدم تحظر SIP أو ما إذا كانت SBC ترفض الطلب.

في BroadWorks Admin، انتقل إلى المستخدم > الأدوات المساعدة > التسجيلات، وتحقق من وجود تسجيل SIP صالح لعميل Webex.

بالنسبة لعملاء Android و iOS للأجهزة المحمولة، لا يقوم تطبيق Webex بالتسجيل في SIP حتى يتم إجراء مكالمة أو تلقيها. تتم إزالة التسجيل عند اكتمال المكالمة. يقوم عملاء الهاتف المحمول بالتسجيل للحصول على إشعارات فورية.

بالنسبة لعملاء الأجهزة المحمولة، تحقق مما يلي:

1. تحقق من تنزيل config-wxt.xml بنجاح ومن العثور على ملف تعريف الجهاز، كما هو موضح لعملاء Windows وMac.

2. تحقق من نجاح التسجيل الفوري.

في سجلات Webex، ابحث عن حالة التسجيل الفوري:

تم تغيير حالة تسجيل OnPush:: تم تغيير حالة التسجيل الفوري، الحالة = غير مسجل

تم تغيير حالة تسجيل OnPush:: تم تغيير حالة التسجيل الفوري، الحالة = مسجلة

في BroadWorks Admin، انتقل إلى المستخدم > الأدوات المساعدة > تسجيلات الإشعارات الفورية وتحقق من وجود تسجيل فوري صالح لعميل Webex.

مشاكل عرض الويب لإعدادات المكالمات

1. لا يظهر زر/رابط العناية الذاتية في تطبيق Webex

من الأعراض المختلفة لهذه المشكلة ظهور الزر/الرابط، ولكن النقر عليه يفتح متصفحًا خارجيًا.

• تحقق من نشر قالب تكوين العميل المطلوب وتعيين علامات CSW بشكل صحيح. (راجع قسم عرض الويب الخاص بإعدادات المكالمات في دليل حلول Webex لـ Cisco BroadWorks).
• تحقق من تسجيل تطبيق Webex للاتصال في BroadWorks.
• تحقق من أن تطبيق Webex هو إصدار حديث يدعم CSWV.

2. صفحة فارغة أو خطأ بعد النقر على زر/رابط العناية الذاتية

بشكل عام، يشير هذا السلوك في تطبيق Webex إلى مشكلة في التكوين أو النشر مع تطبيق CSWV على BroadWorks XSP. اجمع التفاصيل لمزيد من التحقيق، بما في ذلك سجلات CSWV وسجلات الوصول ومستودع config-wxt.xml وملف القالب، ثم قم برفع القضية.

مشكلات المطالبة بالنطاق

يمكن أن تحدث أخطاء تسجيل المستخدم نتيجة الأخطاء التي حدثت في المطالبة بالنطاقات. قبل المطالبة بأي نطاقات، تأكد من أنك تفهم ما يلي:

• يجب ألا يطالب مقدمو الخدمة بنطاقات منظمات العملاء التي يديرونها. يجب عليهم المطالبة فقط بنطاقات هؤلاء المستخدمين الموجودين في المؤسسة الداخلية لمزود الخدمة. يمكن أن تؤدي المطالبة بنطاق المستخدمين في مؤسسة منفصلة (حتى تلك التي يديرها مزود الخدمة) إلى أخطاء التسجيل للمستخدمين في مؤسسة العميل حيث يتم توجيه طلبات مصادقة المستخدم من خلال مزود الخدمة بدلاً من منظمة العميل.
• إذا كانت هناك مؤسستان عميلتان (الشركة A والشركة B) تشتركان في نفس النطاق وطالبت الشركة A بالنطاق، فقد يفشل التسجيل لمستخدمي الشركة B نظرًا لأن طلبات مصادقة المستخدم يتم توجيهها من خلال المؤسسة التي لديها النطاق المطالب به (الشركة A).

  إذا كنت تطالب بأي نطاقات عن طريق الخطأ وتحتاج إلى إزالة مطالبة، فراجع مقالة إدارة نطاقاتك Webex.

رموز أخطاء المستخدم النهائي

يوضح الجدول التالي رموز أخطاء المستخدم النهائي التي يمكن رؤيتها في بوابة تنشيط مستخدم العميل.

رموز الخطأ لمزامنة الدليل

تنطبق رموز الخطأ التالية على Directory Sync.