أستكشاف أخطاء التحقق من صحة قدرة عبارة إستدعاء CVP (CCB) وإصلاحها

المقدمة

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

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

المتطلبات

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

• CVP
• الرد المجازي على Cisco CVP

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

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

• خادم CVP 10.5
• Unified Contact Center Enterprise (UCCE) 10.5

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

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

قبل أن تكون مشكلة سعة البوابة مثيرة للمشاكل، من المهم فهم عملية التحقق من صحة خط الاتصال في CCB. وبشكل أساسي، تحدد العملية أولا عدد الاستدعاءات من جدول CallLback_current مع EventTypeID في (21،22،23)؛   معلق، غير محرز، مؤقت لبوابات ومواقع محددة.

ثانيا، من نفس الجدول CallLback_current، حدد عدد المكالمات المكتملة مع وجود سبب متصل:   EventTypeID = 24 (مكتمل)، وCauseID = 27 (متصل).

أخيرا تضيف العملية هاتين القيمتين وتقارنهما بعدد خطوط الاتصال التي تم تكوينها ضمن خدمة Survivability.tcl.

إذا كانت النتيجة أعلى من حد خطوط الاتصال التي تم تكوينها، فإن العملية تقوم بإرسال فشل (إرجاع 1)، وإلا يتم إرسال "موافق" (إرجاع 0).

في الخلاصة، الصيغة أن يتحقق الشنطة يستعمل ل CCB :

خطوط اتصال CCB < (Callback_current مع EventTypeID في (21،22،23)؛ معلق، InProgress، مؤقت لعبارات محددة) + CallLback_current جدول EventTypeID = 24 (مكتمل)، و CauseID = 27 (متصل)

إذا كانت قيمة خطوط اتصال CCB أقل من فشل التحقق.

الأعراض

لا تحصل المكالمة الواردة على عرض CCB. تنتقل المكالمة مباشرة إلى قائمة الانتظار بغض النظر عن وقت الانتظار التقديري (EWT)

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

الخطوة 1. تجميع سجلات الأنشطة من تطبيق CallLbackEntry من خادم لغة الترميز القابلة للتوسيع الصوتية (VXML).

الخطوة 2. ابحث داخل سجلات النشاط عن أي مكالمة يكون التحقق منها بلا:

Validate_02,data,result,none

مما يعني أن التحقق لم يتم. الحصول على GUID لهذه المكالمة.  تصفية المكالمة حسب طلب النشاط والبحث عن اسم مثل هذا المثال:

start,parameter,callid=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB

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

ValidateHandler:ValidateHandler.exec: ValidateHandler GUID=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB results:none validation status bitmask=0x00000103  

الخطوة 4. تحويل رقم قناع البت إلى ثنائي. أستخدم حاسبة المبرمج: 0001 00000011

الخطوة 5. تحقق من قناع البت الخاص بدليل تقارير CVP لجداول CCB. يجب أن ترى فشل التحقق بسبب "EXCEED_CAPACITY_GW".

الخطوة 6. قم بتقليل المشكلة إلى قائمة انتظار معينة. تحقق من خادم CCB من خادم تقارير CVP لتحديد ما إذا كانت هناك أي قائمة (قوائم) انتظار محددة حيث لا يتم عرض CCB. افتح مستعرض ويب واكتب.

http://{Reporting Server IP address}:8000/cvp/CallbackServlet؟method=diag

هذا مثال لقائمة انتظار حيث CCB مقدم:

هذا مثال على قائمة انتظار حيث لا يتم عرض CCB

الخطوة 7.  تحقق مما إذا كانت قائمة (قوائم) الانتظار يتم توفيرها بواسطة بوابة معينة. تحقق من تكوين البوابة (معلمات تطبيق القدرة على البقاء).

application
 service new-call flash:bootstrap.vxml
 !
 service survivability flash:survivability.tcl
  paramspace callfeature med-inact-det enable
  param ccb id:10.201.198.21;loc:CALO;trunks:512

الخطوة 8. إذا كان التكوين صحيحا، فتحقق من المعلومات المخزنة في قاعدة بيانات Reporting Server (Informix) لتحديد عدد المكالمات على هذه البوابة والموقع المحددين. أنت يستطيع فحصت ب ال CCB id (10.201.198.21 في هذه الحالة) أو موقع (CALO في هذا مثال).

الخطوة 9. على خادم التقارير، قم بالوصول إلى قاعدة بيانات Informix.

افتح مطالبة CMD واكتب: عصيات

انتقل إلى اتصال > اتصال

تحديد مثيل CVP

اكتب username cvp_dbadmin

كلمة مرور النوع

حدد قاعدة بيانات callback@cvp

قم بالخروج والانتقال إلى لغات الاستعلام

الخطوة 10. قم بتشغيل الاستعلام:

حدد count(*) من callback_current حيث الموقع == "calo"؛

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

ملاحظة:  كما هو مشار إليه في دليل تقارير CVP، فإن جدول رد الاتصال هو عرض لجدولين: Callback_current و callback_history. الجدولان متطابقان. كل 30 دقيقة، يتم سحب بيانات المكالمات المكتملة من Callback_Pending ونقلها إلى Callback_History.

الخطوة 12. إذا كانت قيمة خط الاتصال لكل موقع قد بلغت حدودها في جدول Callback_Current ولا توجد أية عمليات رد اتصال في قائمة الانتظار، فإن ذلك يشير إلى وجود مشكلة في نقل سجلات رد الاتصال من Callback_Current إلى جدول Callback_History.

الخطوة 13. تأكد من تشغيل CVPCallbackArchive ضمن مهام الجدول (CVP Reporting Server). انتقل إلى ابدأ -> البرامج -> الملحقات -> أدوات النظام -> المهمة المجدولة.

.

الخطوة 14. إذا انتهت CVPCallbackArchive هذه المهمة من التأكد من أن رمز الخروج هو (0x0).

الخطوة 15. إذا كانت الخطوة 13 و 14 جيدتين، ولكن لا توجد بيانات في جدول callback_history، ستحتاج إلى تحديد سبب عدم إضافة المعلومات في قاعدة البيانات. تحقق من سلامة المعلومات المخزنة في الجدول الحالي والتاريخي.  قم بتشغيل هذا الاستعلام على نافذة DBACCESS CMD غير الرسمية:

Select  count (*) from callback_current where surrogateid in (select surrogateid from callback_historical);

الخطوة 16.  إذا كان العدد 1 أو أعلى، فهذا يعني أن المفتاح الأساسي الموجود على الجدول الحالي موجود بالفعل في الجدول القديم ولا تتم إضافة المعلومات إلى قاعدة البيانات. في معظم هذه السيناريوهات، تتسبب حالة السباق في إدخال سجلات مكررة في الجدول callback_current.

يتم تعيين GUID إلى SUBSTITUTE في جدول قائمة الانتظار. في الحالات التي تنتقل فيها المكالمة من الاستدعاء انتظر إلى نص قائمة انتظار الاستدعاء، يبدو أن هناك نافذة تقوم فيها مهمة الأرشيف بنقل السجلات من الحالي إلى المحفوظات ويقوم التطبيق بإدخال سجل جديد في الجدول الحالي بنفس البديل.  هذا إصدار متعلق هذا cdets CSCuq86400

الحل

الخطوة 1. قاعدة بيانات معلومات الوصول. افتح مطالبة CMD واكتب: عصيات

الخطوة 2. انتقل إلى اتصال > توصيل حدد مثيل CVP. اكتب username cvp_dbadmin واكتب كلمة المرور

الخطوة 3. حدد callback@cvp مخرج قاعدة البيانات وانتقل إلى لغات الاستعلام

الخطوة 4. قم بتشغيل هذه الأوامر:

حذف من callback_current حيث يتم إستبدال EID (حدد بديل من callback_history)؛

في حالة وجود خطأ جدول مؤقت، يجب القيام بما يلي:

جدول الإفلات T1؛

الخطوة 5. قم بتشغيل إجراء SP الذي ينقل المعلومات من جدول الاستدعاء الحالي إلى جدول الاستدعاء التاريخي من نافذة لغة الاستعلام dAccess.

تنفيذ الإجراء sp_arch_callback()؛

الخطوة 6. تأكد من عدم وجود عدد من السجلات في الجدول الحالي كما كان من قبل.

حدد count(*) من callback_current حيث الموقع == "calo"؛

حل دائم

الخطوة 1. انتقل إلى Cisco\CVP\informix_frag وفتح sp_arch_callback.sql في محرر نصوص.

الخطوة 2. قم بإلغاء التعليق على هذا السطر في بداية الملف: —إسقاط الإجراء sp_arch_callback؛   (إزالة — في بداية السطر).

الخطوة 3. أضف هذا السطر: الحذف من callback_current حيث تم التبديل (حدد بديل من callback_history) ؛ بعد

إنشاء سطر الإجراء sp_arch_callback().

الخطوة 4. احفظ الملف.

الخطوة 5. هذا مثال على كيف يجب أن يبدو الجزء الأول من الملف.

{*********************************************************************************
Stored procedure to move completed calls out of the active table into the
historical table.
*********************************************************************************}
drop procedure sp_arch_callback;
create procedure sp_arch_callback()

DEFINE p_ageoff INTEGER;

-- delete any duplicates found in current table.

 

delete from callback_current where surrogateid in (select surrogateid from callback_historical);

 

 

الحل النهائي للاختبار

الخطوة 1.  افتح مطالبة CMD وقم بتشغيل الأمر: dbschema 

dbschema -d الاستدعاء -f sp_arch_callback

ملاحظة: إذا كانت لديك مشكلة في التخويل عند تشغيل الأمر dbschema، قم بتسجيل الدخول ك cvp_dbadmin في خادم التقارير وحاول مرة أخرى.

الخطوة 2. من الإخراج، تأكد من تنفيذ الأمر delete من.