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

المحلول:

للتحقق من هذا:

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 أيضًا.
 
الإعداد الافتراضي هو 1800 ثانية [15 دقيقة] ، وهو أمر قياسي وستحتاج إلى التأكد من تطابق مؤقت TCP على جدار الحماية هنا أيضًا ، ولكن يمكنك زيادة هذا الأمر قليلاً لمعرفة ما إذا كان له تأثير أيضًا على VCS.

هذا تحت ترتيب > البروتوكولات > رشفة:


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