תודה על המשוב.

בעיה
בעת הצטרפות לפגישה ב-Webex עם התקן וידאו רשום CUCM, השיחה מתנתקת תוך 15 דקות בדיוק.

רזולוציה
סקור את השלבים הבאים:

1. פתח את Cisco Unified Communications Manager (CM) Administration.
2. לחץ על מערכת > פרמטרי שירות.
3. תחת בחר שרת ושירות, בתיבת הרשימה הנפתחת שירות , בחר מנהל שיחות של Cisco (פעיל):

4. חפש את טיימר התוקף של הפעלת SIP:

כל המכשירים הרשומים ל-CUCM משתמשים בשעון עצר זה. כאשר המכשיר נמצא בשיחה עם מכשיר מרוחק אחר, אחד הצדדים צריך לרענן את המפגש ושולח הזמנה מחדש או עדכון. יש לשלוח רענון זה לפני ששעון העצר פג תוקף ההפעלה ( 1800/2 = 900 שניות = 15 דקות). אם לא התקבלה הודעת רענון, השיחה מנותקת.

בדוק את טיימר המפגש בהזמנה הראשונית. יש לקבל רענון (INVITE/UPDATE) לפני שתוקף הזמן הזה יפוג:


בהתבסס על המשא ומתן הראשוני של לקוח סוכן משתמש /שרת סוכן משתמש (UAC/UAS), אחד מהמכשירים מרענן את המפגש כשהוא שולח הזמנה מחדש. אם המרענן הוא UAC, ליוזם השיחה יש את האחריות לרענן את המפגש. אם המרענן הוא UAS, השרת צריך לרענן את ההפעלה. אסוף את יומני הרישום של SIP לאיתור באגים משתי נקודות הקצה ובדוק את הפריטים הבאים:

דוגמה: שיחה שבוצעה מהצד A ל-CUCM מהצד B. אם המרענן הוא UAC בצד A ו-UAS בצד B:

1.צד א'      צריך לשלוח את ה-INVITE/UPDATE ל-CUCM.
2.     CUCM צריכה לשלוח הזמנה / עדכון מחדש למפלגה B.
3.     צד B מקבל את ההזמנה מחדש ומגיב להודעה הזו עם אישור 200.
4.     CUCM צריך לשלוח 200 אישור לצד A.

אם מכשיר אחד שולח את הודעת ההזמנה מחדש ל-CUCM, CUCM שולח הזמנה מחדש לצד השני. עם זאת, אם זה לא מתקבל על ידי הצד המרוחק, זה יכול להיות בגלל כמה מכשירי רשת בינהם. ייתכן מאוד שה-INVITE/התגובה מחדש לא תגיע לאחד הצדדים בשל בדיקת SIP או הגדרות רשת.
אם המכשירים לא יוזמים את ההזמנה מחדש, ייתכן שיש בעיה במכשיר. יש לכלול את מרכז הסיוע הטכני של Cisco (TAC) כדי לבצע חקירה נוספת.
 
ברשימת הדברים שיש לנסות [אם עדיין לא עשית זאת] באזור התצורה המתקדם של האזור שעובר ל-Webex:
הפעל את מצב הסינון SIP UDP/IX למצב מופעל [לא ברירת המחדל]:

ובדוק את טיימרים של הפעלת SIP ב-VCS-e גם כן.
 
ברירת המחדל שלנו היא 1800 [30 דקות], שזה סטנדרטי וברצונך לוודא שעוצב ה-TCP בחומת האש שלך תואם גם כאן, אבל תוכל לדרוס את זה קצת כדי לראות אם יש לזה השפעה גם על ה-VCS שלך.

זה נמצא תחת תצורה > פרוטוקולים > SIP:


שים לב שמרווח הרענון (שניות) מוגדר לערך ברירת המחדל. אתה יכול לנסות 3600. אבל שורש הבעיה כאן הוא כאשר ה-FW חושב שמפגש כבר לא נמצא בשימוש [מקרה 1], כאשר VCS באמת חושב שזה בסדר ושהמפגש עדיין פעיל אבל לא מקבל FIN/CLOSE במפגש/יציאה זה ומנסה להשתמש בו מחדש והשיחה מתה. [מקרה 2] הוא שה-FW סוגר כראוי את החיבור ושולח FIN/CLOSE ו-VCS רושם drop/ניקוי שיחה רגילה וגם השיחה מתה. שינוי טיימר ההפעלה כאן שולט רק במועד שבו VCS יוותר בהפעלה לאחר שהוא לא קיבל ACKs כלשהו עבור כל ניסיון תקשורת בנוגע למצב השיחה.
 
אבל זה יכול לעזור לנו לאתר את הבעיה קצת יותר טוב. ייתכן גם שנצטרך להוריד ערך זה בהתאם להגדרת FW עבור טיימר זה.

CAUSE
כאשר שיחות וידאו מתנתקות תוך 15 דקות בדיוק, הבעיה הנפוצה היא שסיום הזמן של TCP שהוגדר ברשת (חומת אש/נתבים) קטן יותר משעון העצר של הפעלת SIP שתוקפה פג. כברירת מחדל ב-CallManager, טיימר התפוגה של הפעלת SIP מוגדר ל-1800 שניות.