فهم بنية JTAPI وتدفق المكالمات في UCCX

المقدمة

يصف هذا المستند الوظائف الأساسية ل JTAPI وبنائه وتدفق المكالمات فيما يتعلق ب UCCX.

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

المتطلبات

توصي Cisco بمعرفة هذه الأدوات والميزات:

• JTAPI - Java Telephony API
• واجهة برمجة التطبيقات
• UCCX - Unified Contact Center Express
• CUCM - مدير الاتصالات الموحدة من Cisco
• CTI - دمج الاتصال الهاتفي عبر الكمبيوتر

توصي Cisco بمعرفة الموضوعات التالية:

• تكوين Cisco Unified Communications Manager (CUCM)
• تكوين Unified Contact Center Express (UCCX)

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

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

• UCCX الإصدار 12.5.1.11002-481
• CUCM الإصدار 12.5.1.1900-146

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

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

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

نظرة عامة على JTAPI

يعمل بروتوكول JTAPI الموحد من Cisco كمعيار واجهة برمجة تم تطويره بواسطة Sun Microsystems للاستخدام مع تطبيقات الاتصال الهاتفي عبر الكمبيوتر القائمة على تطبيق جافا. يقوم Cisco JTAPI بتنفيذ مواصفات Sun JTAPI 1.2 مع ملحقات Cisco الإضافية. تحتاج إلى إستخدام Cisco JTAPI لتطوير التطبيقات التي:

• التحكم في هواتف مدير الاتصالات الموحدة من Cisco ومراقبتها.

• يمكنك توجيه المكالمات باستخدام منافذ دمج الاتصال الهاتفي بجهاز الكمبيوتر (CTI) ونقاط المسار (الأجهزة الظاهرية).

JTAPI و UCCX

يتم إستخدام Cisco Unified JTAPI في مركز اتصال لمراقبة حالة الجهاز وإصدار تعليمات التوجيه لإرسال المكالمات إلى المكان المناسب في الوقت المناسب. بالإضافة إلى ذلك، يتم إستخدام JTAPI لبدء تعليمات التسجيل وإيقافها أثناء إسترداد إحصائيات المكالمات للتحليل وللاستدعاءات المنبثقة للشاشة في تطبيقات CRM، والبرمجة النصية التلقائية، والتحكم في المكالمات عن بعد.

عمارة JTAPI

تجمع Cisco Unified JTAPI، المستخدمة في بيئة مؤسسة، بين توفر المستخدم والموقع والتفضيلات لبيئة مخصصة بشكل فريد للتوجيه القائم على التواجد.

هنا تطبيقات JTAPI:

• يمكن ل JTAPI مراقبة أو إعلامك حول مجموعتي هاتف وخط أو أكثر.
• تستخدم تطبيقات مركز الاتصال نموذج الاتصال الكامل ل JTAPI.
• يوفر JTAPI هذه الوظيفة:
  • التحكم في المكالمات
  • التحكم في الوسائط
  • تفاوض الوسائط

نموذج مراقب JTAPI

يشرح المخطط التالي نموذج الموفر-المراقب الذي يعمل JTAPI عليه.

راصدونا

واجهات المراقبة

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

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

نموذج موفر JTAPI

يشرح المخطط التالي نموذج الموفر الذي يعمل JTAPI عليه:

نموذج ModelProvider لموفر JTAPI

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

مستخدم JTAPI

يتم أخذ لقطات الشاشة التالية من CUCM (إلى اليسار) و UCCX (إلى اليمين) التي توضح كيفية إستخدام تطبيق JTAPI.

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

مقابض P1 و P2

P1 و P2 هما مقابض الموفر. تصبح هذه الأمور مهمة عندما تقوم بفتح موفرين متعددين من نفس التطبيق. من UCCX، أنت تخلق 2 مزود، واحد منهم مسيطر على CTI ميناء و طريق نقطة، الآخر الذي هو مسيطر على الوكيل هاتف يدعى RM-JTAPI مزود. أنت، بما أن UCCX يخلق الموفر الذي يتحكم في منافذ CTI ونقاط المسار أولا أي هو مزود JTAPI P1. الموفر الآخر الذي تقوم بإنشائه بعد P1 هو موفر P2 أو موفر RmCm الذي يعالج أجهزة الوكيل.

إذا شاهدت حدث الاتصال الجديد P1، فأنت تعلم أنه حدث اتصال من منفذ CTI أو نقطة توجيه CTI. إذا رأيت حدث مكالمة جديدة على P2، فأنت تعلم أن هذا حدث اتصال من الهاتف الفعلي. يمكنك إنشاء مستخدم RM-JTAPI ومستخدم JTAPI واحد على جانب CCX ولكن على جانب CUCM، يمكنك رؤية إنشاء إثنين من مستخدمي JTAPI. وذلك لأن كل عقدة CCX تحصل على مستخدم JTAPI خاص بها، ولكنها تشارك مستخدم RM-JTAPI واحد. عندما يخلق أنت زناد على UCCX، هو يحصل أضفت إلى كلا من JTAPI مستعمل. تقوم كلا العقد بفتح موفر بشكل منفصل. لذلك، يتم إعلام أي إجراء يتم إتخاذه على نقطة المسار على كلا عقدتي CCX.

غير ذلك، العقدة الثانوية فقط تجلس هناك وتستمر في الإبلاغ أنها لا تزال العقدة الثانوية. تحتوي كل عقدة على مجموعة منفصلة من منافذ CTI. يتم التحكم في منافذ CTI الخاصة بالعقدة 1 بواسطة jtapi_1. يتم التحكم في منافذ CTI الخاصة بالعقدة 2 بواسطة jtapi_2.

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

إذا رأيت IP مقابل نقطة مسار CTI في CUCM، فإنه واحد من CCX's IP ولكن هذا لا يعني أن عقدة معينة تقوم بتوجيه الاستدعاء.

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

تدفق المكالمات

فيما يلي تسلسل الأحداث المعنية بتدفق مكالمات UCCX:

1. عند وصول المكالمة إلى نقطة مسار CTI، يتم إعادة توجيهها إلى منفذ CTI.
2. يفتح منفذ CTI قناة الوسائط مع برنامج تشغيل IPVMS على مربع UCCX.
3. بمجرد إتخاذ قرار بأن العميل بحاجة إلى تلقي المكالمة، يتم إجراء نقل إستشاري من المنفذ إلى الوكيل.
4. يتم إرسال حدث مكالمة جديد إلى نقطة توجيه CTI.
5. يذهب طلب إعادة التوجيه إلى منفذ CTI.
6. تصبح حالة معرف الاستدعاء خاملة.
7. ثم يأتي حدث إستدعاء جديد آخر للاستدعاء إلى منفذ CTI.
8. إذا كانت إستجابة إعادة التوجيه 0، فإنه جيد، إذا لم يكن صفرا، وهذا يعني أنه فشل.
9. ثم ترسل طلب قبول المكالمة (لم يتم الرد على هذا الطلب، تم قبوله فقط على المنفذ).
10. ثم اقبل نتائج الخطوة على النص، وهذا عندما يأتي طلب الرد على المكالمة في Jtapi.

11. ثم تحصل على إستجابة من المنفذ.

12. تغييرات حالة المكالمة إلى متصل.

13. بعد الحصول على إستجابة من المنفذ، يتم التفاوض مع الوسائط.

14. يرسل Port طلب open_logical_channel الذي يشارك فيه المنفذ الخاص به و ip الذي يريد من الطرف البعيد إرسال RTP إليه.

15. قبل فتح القناة المنطقية، يتم إنشاء اتصال ببرنامج تشغيل IPVMS على مربع UCCX ويفتح تدفق RTP.

16. الحدث التالي هو حدث بدء_الاستقبال الذي يخبرنا بالمعلومات النهائية البعيدة (أي ip والمنفذ الخاص بجهاز الاتصال).

17. بعد ذلك، تستطيع الحصول على بث الحدث مثل أي إشارة إعلامية أخرى.

18. الآن، أنت تستمع إلى رسالة التوجيه المتبادل بين الأنظمة والمستندات.

19. الآن عندما تصل المكالمة إلى خطوة في البرنامج النصي الذي يمكن المكالمة من النقل إلى الوكيل، سترى CallSetupTransferRequest.

20 - وخلافا للرسالة الأولى، فإن هذه هي عملية نقل للاستشارة وليست عملية إعادة توجيه.

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

22. مثل أي عملية نقل تشاور أخرى، هذا هو منفذ CTI يضغط على زر النقل للمرة الأولى على الهاتف.

23. في عملية نقل منتظمة للتشاور، هناك مسار إعلامي بين A و C، ولكن في هذا تأمر CUCM بعدم القيام بذلك حيث لا يوجد معنى لإنشاء وسائط إعلامية بين UCCX والوكيل.

24. إذا أنت ذاهب للقيام باستشارة نقل بدون عمل قطع وسائط بين الوكيل ومنفذ CTI.

25. عند هذه النقطة، يضع منفذ CTI المتصل قيد الانتظار ونرى حالة الاتصال التي تم تغييرها event=HOLD.

26. الآن يمكنك مشاهدة حدث إستدعاء جديد من منفذ CTI إلى جهاز الوكيل. (باستخدام معرف المكالمة الأصلي، ولكن مجموعة فرعية منه وحدث P2.)

27. إذا قمت بالبحث في معرف مكالمة حدث P2، فسترى الرسالة التالية كطلب CallResponse مما يعني أن العميل قد التقط المكالمة.

28. بمجرد أن تعرف أن الوكيل قد التقط المكالمة (باستخدام P2) وأن المكالمة في حالة اتصال على جانب منفذ CTI أيضا (باستخدام P1)، بعد ذلك يمكنك رؤية نقطة المسار CallDirectTransferRequest، مما يعني أنه تم الضغط على زر النقل للمرة الثانية.

29. الآن حيث أن منفذ CTI يعرف أن الوكيل قد التقط المكالمة، لا توجد نقطة انتظار، يرسل على الفور CallDirectTransferRequest نقطة وهي منفذ CTI يضغط على زر النقل مرة ثانية كما هو موضح أعلاه.

30. الآن، ساق الاتصال الأصلية (ساق التي كانت معلقة) هي التي بقيت على قيد الحياة.

31. يتم تدمير ساق الاتصال الأخرى (بين المنفذ والوكيل).

32. عند هذه النقطة، يتم تأسيس CUCM و UCCX من الصورة و RTP بين المتصل والوكيل من خلال البوابة.

يشرح المخطط التالي تدفق المكالمات المذكور سابقا بطريقة ملخصة.

ملخص تدفق مكالمات JTAPI

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

تمكين سجلات JTAPI وتجميعها

تمكين تصحيح أخطاء JTAPI

الرجاء التحقق من هذه الخطوات لتمكين مستويات تصحيح أخطاء JTAPI.

1. تسجيل الدخول إلى UCCX.
2. انتقل إلى خدمة CCX.
3. الانتقال إلى التتبع.
4. انتقل إلى التكوين.
5. من تحديد الخدمة المنسدلة، حدد عميل Cisco Unified CM Telephony.
6. حدد خانة الاختيار تصحيح الأخطاء.
7. حدد كل خانات الاختيار ما عدا Misc_Debuing.

تجميع تصحيح أخطاء JTAPI

الرجاء التحقق من هذه الخطوات لتمكين مستويات تصحيح أخطاء JTAPI من RTMT أو CLI.

من RTMT

1. أداة مراقبة الوقت الفعلي للدخول إلى CCX.
2. انقر على التسجيل والتتبع المركزي.
3. انقر فوق تجميع الملفات.
4. حدد عميل JTAPI لجميع الخوادم.
5. انقر فوق Next (التالي).
6. حدد الطوابع الزمنية والمكان الذي تريد حفظ ملفات السجل إليه.

من CLI

موقع سجل JTAPI

activelog /uccx/log/jtapi

أمر تجميع سجلات JTAPI:

ضغط ملف get activelog /uccx/log/JTAPI/* المتكرر

الصيغة:

الحصول على {activelog|inactivelog|install} file-spec [options]

الملف - مواصفات الملف الإلزامي المراد نقله

الخيارات الاختيارية لأشهر ترحيل الوقت|أسابيع|أيام|ساعات|قيمة الوقت بالدقائق

                                 ص ص ص:م:م/د/ص ص ص ص:مم:مم/د/ص

                                 طابق ذروي

                                 تكرار

                                 كمادة

5 طرق لتنزيل السجلات استنادا إلى الطابع الزمني

Reltime—الفترة الزمنية النسبية، المحددة كدقائق | ساعات | يوما/أيام | أسابيع | قيمة الأشهر

ABSTIME—الفترة الزمنية المطلقة، المحددة ك hh:mm:MM/DD/YY HH:mm:MM/DD/YY

مطابقة—مطابقة سلسلة معينة في اسم الملف، محددة كقيمة سلسلة

التكرارات—احصل على كل الملفات، متضمنا المجلدات الفرعية

يتيح لك خيار الضغط تنزيل الملفات بتنسيق مضغوط.

روابط مرجعية

• دليل مطوري JTAPI
• مستويات تتبع UCCX