المقدمة
يصف هذا المستند دور Cisco Customer Voice Portal (CVP) وقيوده فيما يتعلق بمعلمة تحديث جلسة العمل الخاصة بالمكالمة.
المتطلبات الأساسية
المتطلبات
لا توجد متطلبات خاصة لهذا المستند.
المكونات المستخدمة
تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
معلومات أساسية
يعمل CVP كوكيل مستخدم من الخلف إلى الخلف (B2BUA) بين المدخل وبوابة VoiceXML (VXML)، أو Cisco Unified Communications Manager (CUCM) أو أي نقطة نهاية مخرج أخرى. يتم التفاوض على مؤقت جلسة العمل بين نقطتي نهاية على أي من جانبي CVP. وهو يمرر كل الرؤوس من ساق إلى أخرى.
هناك ثلاث نقاط في المكالمة حيث يقوم CVP ببدء إعادة الدعوة نحو ساق الدخول بنفسه:
- بعد الانتهاء من IVR، يرسل CVP إعادة الدعوة إلى جانب المتصل للحصول على رد المتصل.
- بعد إجابات الوكيل (أو رجل الوكيل التالية بسبب إعادة الاستعلام)، يرسل CVP REINVITE نحو ساق الدخول
- بعد أن ينتهي الهمس، يقوم CVP بإرسال دعوة مكررة نحو ساق الدخول.
المشكلة
إذا كان هناك مؤقت جلسة سابق تم التفاوض عليه بين المدخل و IVR نقطة النهاية (مع CVP فيما بين)، فإن CVP يتخطى الرؤوس ذات الصلة بمؤقت جلسة العمل في REINVITE، يمكن أن يفترض نقاط النهاية الأخرى كتحديث. ونتيجة لذلك، يتم إسقاط المكالمة بسبب انتهاء صلاحية الجلسة القديمة (على سبيل المثال: عمليات إسقاط المكالمات عند 30 دقيقة). يوضح هذا الرسم التخطيطي السيناريو:
مع CVP 11.6، يأخذ CVP على رأس الجلسة في الحالات المدرجة. في جميع الحالات الأخرى، يمكن أن تنقل CVP هذه الرؤوس من ساق إلى أخرى.
معلمة تحديث المعلمة Case Ingress-UAC
إستجابة لطلب الدعم
—
1 y بلا وحدة uas أو uac
UAC 2Y
3 y uas
هذه هي التغييرات التي تم إدخالها عندما يجيب الوكيل:
- يحدد CVP أي الوكيل ستجيب عليه IP ويعين على ما هو في طلب الإجابة، فإنه يحدد ما يجب إرساله إلى المدخل داخل الرأس.
- عندما يقوم CVP بإعادة بدء إعادة الدعوة نحو المدخل (يبدأ CVP لنقل الوكيل أو بعد تنفيذ الهمس)، فإنه يعين الدور للدخول بناء على ما تم إستلامه في 200 OK من CUCM. التفاصيل في الجدول 1-1.
- بالنسبة لرسالة الدعوة المرسلة إلى ساق الهمس، يمكنك إما تجاهل أو تعيين مصدر التحديث بناء على ما تم إستلامه في 200 OK من CUCM. توجد نقطة الهمس المؤقت 15s على بوابة VXML. ومن ثم فالمسألة ليست مسألة.
وفيما يلي الحالات المختلفة التي تستجيب فيها الوكيل ساق للاتصال (دون همس):
الجدول 1-1
يرسل مدخل في دعوة أولية |
رد IVR |
ما يذهب إلى CUCM |
شو بتجاوب ال 200 اوكي |
ما يجب أن يرسل CVP في إعادة توجيه الدعوة إلى المدخل |
انتهاء صلاحية جلسة العمل: <value> |
انتهاء صلاحية جلسة العمل: <value>؛refresh=uac |
انتهاء صلاحية جلسة العمل: <value> |
جلسة العمل-انتهاء الصلاحية: <value>؛refresh=uac |
انتهاء صلاحية جلسة العمل: <value>؛refresh=uas |
انتهاء صلاحية جلسة العمل: <value> |
انتهاء صلاحية جلسة العمل: <value>؛refresh=uas |
انتهاء صلاحية جلسة العمل: <value> |
انتهاء صلاحية جلسة العمل: <value>؛refresh=uas |
جلسة العمل-انتهاء الصلاحية: <value>؛refresh=uac |
انتهاء صلاحية جلسة العمل: <value>؛refresh=uas |
انتهاء صلاحية جلسة العمل: <value>؛refresh=uas |
انتهاء صلاحية جلسة العمل: <value>؛refresh=uas |
انتهاء صلاحية جلسة العمل: <value>؛refresh=uas |
جلسة العمل-انتهاء الصلاحية: <value>؛refresh=uac |
انتهاء صلاحية جلسة العمل: <value>؛refresh=uac |
انتهاء صلاحية جلسة العمل: <value>؛refresh=uac |
انتهاء صلاحية جلسة العمل: <value>؛refresh=uac |
جلسة العمل-انتهاء الصلاحية: <value>؛refresh=uac |
انتهاء صلاحية جلسة العمل: <value>؛refresh=uas |
من الجدول 1.1، يمكن ل CVP تحديد دور جانب الوكيل عندما يستلم 200 OK. في جميع الحالات، تقوم إعادة الدعوة نحو الدخول بتغيير الدور لضمان الاهتمام بالمنعشات.
عند تمكين الهمس، يتم بالفعل الإجابة على نقطة وصول العميل (INVITE/200/ACK Exchange)، يرسل CVP REINVITE باتجاه الدخول وبمجرد تلقي 200 OK، يتم إرسال REINVITE إلى الوكيل.
من أجل REINVITE تجاه المدخل، أستخدم الجدول 1.1 ولإعادة الدعوة نحو الوكيل، أستخدم هذا الجدول:
شو بيطلع من مدخل 200 ماشي لإعادة الدعوة |
ما يجب أن يقوم CVP بإرسال إعادة الدعوة إلى الوكيل |
جلسة العمل-انتهاء الصلاحية: <value>؛refresh=uac |
انتهاء صلاحية جلسة العمل: <value>؛refresh=uas |
انتهاء صلاحية جلسة العمل: <value>؛refresh=uas |
جلسة العمل-انتهاء الصلاحية: <value>؛refresh=uac |
الحل
يمكن إستلام دعوة أولية من المدخل مع أي من الخيارات:
انتهاء صلاحية جلسة العمل: <value>
انتهاء صلاحية جلسة العمل: <value>؛refresh=uac
انتهاء صلاحية جلسة العمل: <value>؛refresh=uas
من الناحية المثالية، للحفاظ على بساطة التكوين، تتمثل توصية مستوى الحل في تكوين بوابة الدخول للتحديث=uac حتى يكون للدعوة التي يتم استقبالها بواسطة CVP الدور المحدد، وإلا فإن 200 OK من IVR تحدد الدور.
يتم تناول هذا العمل من خلال خطأ التوثيق.
جلسة-تنتهي تشكيل يحتاج على مدخل
يمكن معالجة الاستخدام المحدد هنا:
- هناك أختلاف في الساقين بالنسبة للتفاوض بشأن تحديث جلسة العمل، وذلك نتيجة طلب تخفيض الساعة 30 دقيقة.
- يكمن الاختلاف في أن Telco لا يقوم بتحديث جلسة العمل و CUCM يريد تحديث جلسة العمل كمعلمة إلزامية (يتطلب: مؤقت) في تدفق المكالمة هذا (Telco-CUBE-CVP-CUCM).
- في هذه الحالة، يحتاج إما CVP أو مدخل العبارة (CUBE) إلى أخذ دور تحديث الجلسة لإرسال دعوة التحديث إلى CUCM.
- ولكن لا يمكن ل CVP إنشاء دعوات التحديث. لا يمر إلا بين المكعب و CUCM.
- لذلك عليك أن تجعل CUBE منعشا هنا.
- لعمل CUBE كتحديث، يمكنك تطبيق هذا التكوين على CUBE ومراقبة الاستدعاءات ل 30 دقيقة. drop. ولا يؤثر هذا الأمر على الإنتاج ويتم تطبيق تغيير التكوين على الفور.
conf t
voice service voip
sip
min-se 1800 session-expires 1800
session refresh
end
أسئلة شائعة في سيناريوهات محددة:
1. من هو المنعش عندما يسمع الوكيل همسا. في هذه الحالة CVP هو ال UAC للعامل وساق الهمس وما قيمة الجلسة-تنتهي؟
في هذه الحالة، سيتم تعيين عبارة المتصل/الدخول كمنعشت.
2.لماذا يجب أن يقوم CVP بتخزين التحديث من المدخل عندما يعلم CVP مسبقا متى يبدأ معاملة عميل أو معاملة خادم. لا يدعم CVP تحديث جلسة العمل، ويمكنه دائما تعديل/إضافة الرأس أثناء إرساله إعادة الدعوة إلى الدخول كتحديث ؟
في الوقت الحالي، لا يدعم بروتوكول CVP المجموعة الثالثة، حيث تلعب بوابة CUCM/VXML دور التحديث. في كلتا الحالتين، يحتاج CVP إلى حفظ المعلومات حول من يتولى دور التحديث، إما GW أو CUCM. وبناء على ذلك، فإنه يتضمن معلمة التحديث في الطلب والاستجابة الصادرين.