مشكلة
عند الانضمام إلى اجتماع Webex باستخدام جهاز فيديو مسجل من CUCM، يتم قطع الاتصال في 15 دقيقة بالضبط.

RESOLUTION
راجع الخطوات التالية:

1. افتح إدارة Cisco Unified Communications Manager (CM).
2. انقر فوق نظام > معلمات الخدمة.
3. تحت حدد الخادم والخدمة، في ال خدمة مربع القائمة المنسدلة ، حدد مدير اتصالات Cisco (نشط):

4. بحث عن تنتهي جلسة SIP الموقت:

تستخدم جميع الأجهزة المسجلة في CUCM هذا المؤقت. عندما يكون الجهاز في مكالمة مع جهاز آخر عن بعد ، يتعين على أحد الأطراف تحديث الجلسة وإرسال دعوة إعادة أو تحديث. يجب إرسال هذا التحديث قبل نصف مؤقت انتهاء الجلسة (1800/2 = 900 ثانية = 15 دقيقة). إذا لم يتم استلام رسالة تحديث ، فسيتم فصل المكالمة.

تحقق من مؤقت الجلسة في INVITE الأولي. يجب استلام تحديث (INVITE / UPDATE) قبل انتهاء صلاحية هذا الوقت:


استنادًا إلى التفاوض الأولي لـ User Agent Client / User Agent Server (UAC / UAS) ، يقوم أحد الأجهزة بتحديث الجلسة عندما يرسل Re-INVITE. إذا كانت أداة التنشيط هي UAC ، فإن البادئ بالمكالمة يتحمل مسؤولية تحديث الجلسة. إذا كان التحديث هو UAS ، يجب على الخادم تحديث الجلسة. اجمع سجلات تصحيح أخطاء SIP من كلا نقطتي النهاية وتحقق من هذه العناصر:

مثال: مكالمة تم إجراؤها من الطرف "أ" إلى "CUCM" إلى الطرف "ب". إذا كان التنشيط هو UAC في الطرف "أ" و "UAS" في الطرف "ب":

1.     يتعين على الطرف "أ" إرسال دعوة إعادة / تحديث إلى CUCM.
2.     يتعين على CUCM إرسال دعوة إعادة / تحديث إلى الطرف "ب".
3.     يتلقى الطرف "ب" دعوة إعادة الدعوة ويرد على تلك الرسالة بـ 200 موافق.
4.     يتعين على CUCM إرسال 200 موافق إلى الطرف أ.

إذا أرسل أحد الأجهزة رسالة re-INVITE إلى CUCM ، فإن CUCM يرسل دعوة إعادة إلى الطرف الآخر. ومع ذلك ، إذا لم يتم استلام هذا من قبل الجانب البعيد ، فقد يكون ذلك بسبب وجود بعض أجهزة الشبكة بينهما. من المحتمل جدًا ألا تصل إعادة الدعوة / الاستجابة إلى أحد الجانبين بسبب فحص SIP أو إعدادات الشبكة.
إذا لم تبدأ الأجهزة في إعادة الدعوة ، فقد تكون هناك مشكلة في الجهاز. قم بإشراك مركز المساعدة الفنية Cisco (TAC) من أجل مزيد من التحقيق.
 
في قائمة الأشياء التي يجب تجربتها [إذا لم يكن ذلك بالفعل] في منطقة التكوين المتقدم للمنطقة ، انتقل إلى Webex:
أدر ال وضع مرشح SIP UDP / IX إلى على [ليس الافتراضي]:

وتحقق من مؤقتات جلسة SIP على VCS-e أيضًا.
 
لدينا الافتراضي هو 1800s [30 دقيقة]، وهو معيار وسترغب في التأكد من أن مؤقت TCP على جدار الحماية الخاص بك يتطابق هنا أيضًا، ولكن يمكنك رفع هذا قليلاً لمعرفة ما إذا كان له تأثير أيضًا على VCS الخاص بك.

هذا ضمن التكوين > البروتوكولات > SIP:


لاحظ أن الفاصل الزمني لتحديث الجلسة (الثواني) تم تعيينه على القيمة الافتراضية. يمكنك تجربة 3600. لكن الجذر الفعلي للمشكلة هنا هو عندما يعتقد مهاجم العمل أن الجلسة لم تعد قيد الاستخدام [الحالة 1] ، عندما يعتقد VCS أن الأمر على ما يرام وأن الجلسة لا تزال منتهية ولكنها لا تتلقى FIN / إغلاقًا على ذلك جلسة / منفذ ومحاولات إعادة استخدامه وتموت المكالمة. [حالة 2] هو مهاجم يغلق الاتصال بشكل صحيح ويرسل FIN / إغلاق ويسجل VCS إسقاط / مقاصة مكالمة عادية وتموت المكالمة أيضًا. يؤدي تعديل مؤقت الجلسة هنا فقط إلى التحكم في الوقت الذي سيتخلى فيه VCS عن الجلسة بعد فشلها في تلقي أي ACK لأي محاولة اتصال فيما يتعلق بحالة المكالمة.
 
يمكن أن يساعدنا في تحديد المشكلة بشكل أفضل قليلاً. من الممكن أيضًا أن نحتاج إلى خفض هذه القيمة بناءً على إعداد FW لهذا المؤقت.

لأنه
عند قطع مكالمات الفيديو في 15 دقيقة بالضبط، تكون المشكلة الشائعة هي أن مهلة TCP التي تم تكوينها على الشبكة (جدار الحماية/أجهزة التوجيه) أقل من مؤقت انتهاء صلاحية جلسة SIP. بشكل افتراضي في CallManager، يتم تعيين مؤقت انتهاء صلاحية جلسة SIP إلى 1800 ثانية.