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

المقدمة

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

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

المتطلبات

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

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

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

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

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

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

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

قبل أن تكون مشكلة سعة البوابة مثيرة للمشاكل، من المهم فهم عملية التحقق من صحة خط الاتصال في CCB. وبشكل أساسي، تحدد العملية أولا عدد الاستدعاءات من جدول CallLback_current مع EventTypeID (212223)؛ قيد الانتظار، InProgress، مبدئي لبوابات ومواقع محددة.

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

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

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

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

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

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

الأعراض

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

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

الخطوة 1. تجميع سجلات الأنشطة من تطبيق CallbackEntry من خادم لغة الترميز القابلة للتوسيع الصوتي (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. قم بتحويل رقم قناع البت إلى ثنائي. أستخدم حاسبة مبرمجة 00010000011

الخطوة 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 ضمن Schedule Tasks (خادم تقارير CVP). انتقل إلى ابدأ -> البرامج -> الملحقات -> أدوات النظام -> المهمة المجدولة.

.

الخطوة 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 والنوع: dbacces

الخطوة 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. من المخرج، تأكد من تنفيذ الأمر حذف من.