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

RESOLUTION
בחן את השלבים הבאים:

1. מנהל התקשורת המאוחד הפתוח של סיסקו (CM).
2. לחץ על מערכת > פרמטרים של שירות.
3. בקטע בחר שרת ושירות, בתיבת הרשימה הנפתחת של השירות, בחר Cisco Call Manager (פעיל):

4. חפש את שעון העצר להפעלת SIP:

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

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


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

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

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

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

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

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


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

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