בעיות המשפיעות על שיחות נכנסות של ניתוב ישיר

ייתכן שתיתקל בבעיות בעת קבלת שיחות מסוג Public Switched Telephone Network (PSTN) באמצעות ניתוב ישיר. מאמר זה דן בחלק מבעיות אלה ומספק פתרונות שתוכל לנסות.

אין צליל צלצול כאשר Teams מקבל שיחה נקודת קצה של PSTN

בעיה זו מתרחשת בתרחיש הבא:

כאשר לקוח Microsoft Teams מקבל שיחה, הוא שולח תחילה הודעת צלצול SIP 180 ולאחר מכן שולח הודעת התקדמות הפעלה של SIP 183 יחד עם הצעת מדיה (SDP).

בהתאם לתקני RFC 3261 ו- RFC 3960, כאשר נקודת הקצה המשמשת את מתקשר מקבל הודעת צלצול SIP 180, עליו ליצור את צליל הצלצול באופן מקומי. אם המכשיר של המתקשר מקבל הודעת התקדמות הפעלה של SIP 183 עם SDP, הוא מאפשר ליעד (לקוח Teams בתרחיש זה) להשמיע שמע או צלצול לפני שההפעלה מתקבלת על-ידי המשתמש המכונה. שמע כזה מוכר כמדיה מוקדמת.

עם זאת, מכשירים ומובילים מסוימים של המתקשר מפסיקים ליצור את צליל הצלצול באופן מקומי כאשר הם מקבלים הודעת התקדמות הפעלה של SIP 183. מצב זה מתרחש למרות שהמכשירים והמובילים אמורים להמשיך ליצור את צליל הצלצול עד לקבלת מנות המדיה בפועל.

פתרון

כדי לפתור את הבעיה, עליך לעדכן את תצורת בקר גבול ההפעלה (SBC) כדי לטפל בהודעות SIP 18x מרובות.

רוב מחשבי ה- SBC מציעים אחת מהאפשרויות הבאות של צמצום סיכונים:

• העבר רק את ההודעה הראשונה של SIP 18x והתעלם מההודעות הבאות עד שהשיחה נענתה או הסתיימה. אפשרות זו מוצעת על-ידי רכיבי SBC של AudioCodes, לדוגמה.
• הסר את פרטי ה- SDP מהודעת התקדמות ההפעלה של SIP 183 ולאחר מכן שנה את ההודעה להודעת צלצול SIP 180. אפשרות זו מוצעת על-ידי Metaswitch SBCs, לדוגמה.

לקבלת הוראות לעדכון כללי המניפולציה של SIP ב- SBC, עיין בתיעוד הספציפי למודל SBC שלך ופנה לספק SBC לקבלת אפשרויות מומלצות אחרות.

הודעות מרובות אודות שיחות שלא נענו

כאשר Teams מקבל שיחה ודחה אותה משום שהמשתמש עסוק או אינו מעוניין לקבל את השיחה בשלב זה, ספק השירות של PSTN או SBC עשוי לנסות שוב את השיחה מספר פעמים. Teams מפרש כל אחת מהשיחות הבאות בתור שיחות נפרדות, ומציג הודעות מרובות על שיחות שלא נענו.

בעיה זו מתרחשת מאחר שתקני תקשורת שונים, כגון תקן RFC 4497 ו- ND1017:2006/07 בתקן RFC 4497 ו- ND1017:2006/07, ממפים את אותו קוד תגובה של SIP לקוד סיבה אחר של Q.850.

לדוגמה, RFC 4497 ממפה את קוד התגובה SIP 486 ל- Q.850 גורם לקוד 34, ו- ND1017:2006/07 (שבו משתמש ניתוב ישיר) ממופה את קוד 486 ל- Q.850 גורם לקוד 17. עקב הבדל זה, ספקי PSTN המשתמשים בתקן RFC 4497 מפרשים את הסיבה לכך ש- Teams דחה את השיחה באופן שגוי. לכן, ספקי PSTN לנסות שוב את השיחות כמה פעמים.

פתרון

כדי לפתור את הבעיה, עדכן את כללי המניפולציה של SIP ב- SBC כדי להסיר את Q.850 כדי לגרום לקוד הממופה לקוד תגובת SIP 486, או שנה את קוד הגורם מ- 34 ל- 17. לקבלת הוראות לעדכון כללי המניפולציה של SIP, עיין בתיעוד הספציפי למודל SBC שלך.

אם עדכון הכללים אינו פותר את הבעיה, ייתכן שה- SBC, התקן רשת בנתיב התקשורת, או שספק ה- PSTN שלך מנסה שוב לבצע את השיחה לאחר שהיא מקבלת קוד תגובה מסוג SIP 4xx . אופן פעולה זה אינו מומלץ. במצב זה, עדכן את התצורה של SBC והתקני הרשת, או בקש מספק PSTN לעדכן את התצורה שלו כדי לוודא שהוא לא מנסה שנית שיחה לאחר שהוא מקבל תגובת SIP 4xx כדי לסיים את השיחה.

מזהה מתקשר שגוי (CLI) מוצג עבור שיחות נכנסות

כאשר Teams מקבל שיחה, הוא מציג From את מספר מתקשר שצוין בכותרת בהודעה SIP INVITE. עם זאת, ספקי PSTN מסוימים עשויים להשתמש P-Asserted-Identity בכותרת From העליונה במקום בכותרת כדי לאחסן את המספר של מתקשר. במצב זה, המידע המוצג למשתמש Teams שגוי.

פתרון

כדי לפתור בעיה זו, בדוק אם ספק PSTN שלך משתמש בכותרת P-Asserted-Identity העליונה. אם כן, קבע את התצורה של SBC לשכתב From את תוכן הכותרת במידע מהכותרת P-Asserted-Identity העליונה.

כדי לשכתב את הכותרת From העליונה, עיין בתיעוד הספציפי למודל SBC לקבלת הוראות.

הערה

אם הכותרת From העליונה מכילה את הטקסט "אנונימי" כמידע שלה, Teams ממיר אותה לפעמים למספר ומציג 266696687 במקום זאת.

שיחות נכנסות מסומנות באופן שגוי כ"דואר זבל צפוי"

אם סינון הודעות זבל ( spam) עבור שיחות זמין, מזהה מתקשר של כל השיחות הנכנסות מסומן ומוקצים לו ניקוד של דואר זבל. אם הציון עבור מזהה מתקשר גבוה מסף מסוים, Teams מציג הודעה על כך שהשיחה עשויה להיות הודעת זבל.

פתרון

כדי להפחית את הסיכוי למספר טלפון של מתקשר שסומן כדואר זבל, ודא שהמספר מופיע בתבנית E.164.

שיחות נכנסות אינן חסומות כצפוי

עליך לקבוע את התצורה של Teams לחסום שיחות ממ זהי מתקשרים התואמים לקריטריונים ספציפיים מוגדרים מראש. עם זאת, אתה ממשיך לקבל שיחות מהמספרים מסוג זה.

בעיה זו נגרמת From בדרך כלל על-ידי אי-התאמה בין תבנית מזהה מתקשר שצפויה על-ידי הביטוי המשמש למסך שיחות נכנסות והתבנית של מזהה מתקשר בכותרת של הודעת ה- SIP.

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

פתרון

כדי לפתור בעיה זו, עדכן את הביטוי המשמש כדי לבדוק שיחות נכנסות על-ידי הוספת סימן החיבור (+) כתו אופציונלי. ביטוי מתוקן זה מכסה תבניות מרובות של מזהי מתקשרים, והוא שימושי במיוחד אם אתה משתמש הן בתוכניות ניתוב ישיר והן בתוכניות שיחות שבהן מספרים מוצגים בתבניות שונות.

השהיה בעת מענה לשיחות PSTN ב- Teams

כאשר Teams מקבל שיחה נקודת קצה של PSTN, אתה נתקל בעיכוב במענה לשיחה או אינך שומע שמע במשך כמה שניות לאחר ש- Teams עונה לשיחה.

בעיות אלה נגרמות בדרך כלל על-ידי הזמנה מחדש מרובה של SIP הנשלחות בין SBC לבין ה- Proxy של SIP לפני שהשיחה מחוברת בהצלחה. הדבר נפוץ במיוחד בתרחישים הכוללים מעקף מדיה או מיטוב מדיה מקומי הדורשים כמה הזמנה מחדש באמצעות עיצוב. בנוסף, במצב כגון כאשר SBC אינו מציע את כתובת ה- IP המתאימה של המדיה ההזמנה המקורית, SBC חייב לשלוח הזמנה מחדש המכילה את המידע הנכון. אם ההזמנה מחדש מ- SBC מתקבלת על-ידי ה- SIP Proxy בסדר הלא נכון או בזמן הלא נכון (וגרם למצב מירוץ), ביצוע ההזמנה מחדש עשוי להימשך זמן רב יותר. מצב זה עלול לגרום לעיכובים בשמע.

פתרון

כדי לפתור בעיות אלה, עדכן את תצורת SBC שלך. ודא שהיא מציעה את כתובת ה- IP של המדיה ש להניח שתציע כברירת מחדל כדי למזער את מספר ההתחדשות. לדוגמה, אם רוב השיחות צפויות ממשתמשים פנימיים, קבע תחילה את תצורת SBC כך שתציע IP פנימי. לקבלת הוראות מפורטות אודות תצורת SBC, עיין בתיעוד הספציפי למודל SBC שלך.

שיחות טיפות לאחר משך זמן ספציפי

ב- Teams, שיחות המתבצעות ושיחות נכנסות שעדיין מנסות להתחבר עשויים לרדת מסיבות שונות.

בהתבסס על משך הזמן שאחריו השיחה תם, נסה את הרזולוציות הפועלות עבור התרחיש שלך.

שיחות ישחררו לאחר ארבע שניות בערך

בעיה זו נגרמת בדרך כלל על-ידי קישוריות ירודה או בעיית תקשורת קיימת בין SBC לבין ה- Proxy של SIP. לדוגמה:

• ייתכן ש- SBC לא יקבל את ההודעה SIP 100 מנסה מכיוון שההודעה חסומה על-ידי חומת אש או אינה נשלחת עקב בעיות רשת.
• ה- SBC מקבל את הודעת ה- SIP אך אינו מאשר אותה על-ידי שליחת הודעת SIP ACK.

פתרון

כדי לפתור בעיה זו, עדכן את תצורת ה- SBC והרשת שלך כדי לאפשר לתעבורה אל ומ כל טווחי כתובות ה- IP המשמשים את התכונה ניתוב ישיר עבור איתות SIP. בנוסף, ודא שה- SBC שולח הודעות בהתאם לתהליך הרגיל המשמש להעברת אותות SIP.

לקבלת הוראות מפורטות אודות תצורת SBC, עיין בתיעוד הספציפי למודל SBC שלך.

שיחות טיפות לאחר כ- 10 עד 20 שניות

אם שיחה נכנסת משחררת בין 10 ל- 20 שניות של ניסיון להתחבר, ולא קיים שמע, ייתכן שהסיבה לכך היא שלא התקבל מידע מדיה ב- Timeframe זה או בבדיקת הקישוריות האינטראקטיבית Connectivity Establishment (ICE) נכשלה. במצב זה, Teams משחרר את השיחה.

פתרון

כדי לפתור בעיה זו, ודא שהמועמדים הנכונים ל- ICE נכללים בהודעה SDP מ- SBC. כמו כן, עדכן את תצורות הרשת וחומת האש בהתאם כדי לוודא שהם יכולים לטפל בבקשות ובתגובות של מועמדים ל- ICE.

שיחות מקומיות לאחר מספר דקות

שיחה מתמשכת מתשחררת מבלי להחזיר קוד שגיאה לאחר שהוא מתחבר ו נשארת פעילה בין 10 ל- 60 דקות. תרחיש זה עשוי להתרחש אם בעיה משפיעה על SESSION-EXPIRES שעון העצר של ההפעלה או מנגנון רענון ההפעלה שצוין בכותרת של הודעת SIP INVITE. השיחה מתוזמנת להסתיים SESSION-EXPIRES לאחר השעה שצוינה בכותרת העליונה, אלא אם נשלחת הזמנה מחדש כדי לרענן את ההפעלה לפני תום הזמן.

בדוגמה הבאה, הכותרת SESSION-EXPIRES מציינת שהשיחה תסתיים לאחר 1,800 שניות (30 דקות):

SESSION-EXPIRES : 1800;refresher=uac

הערה

• הזמנה מחדש נשלחת בדרך כלל במחצית הדרך של הזמן שצוין על-ידי שעון העצר של ההפעלה.
• אם ערך הפרמטר refresheruacבכותרת הוא , הצד השולח את הודעת SIP INVITE אחראי לשליחת ההזמנה מחדש כדי לרענן את ההפעלה.
• אם ערך הפרמטר refresheruasבכותרת הוא , הצד המקבל את הודעת SIP INVITE אחראי לשליחת ההזמנה מחדש כדי לרענן את ההפעלה.

פתרון

כדי לפתור בעיה זו, עדכן את תצורת SBC שלך כדי לוודא שה הצד הנכון שולח הודעת הזמנה מחדש בזמן המתאים לפני שתוקף שעון העצר של ההפעלה יפוג.

בעיות שעון עצר של הפעלה עשויות להתרחש גם בחלקים אחרים של השיחה, כגון ספק שירות PSTN בנתיב התקשורת. אם השיחה נכשלת אצל ספק PSTN, היא שולחת הודעת SIP BYE ל- SBC. הודעה זו נשלחת לאחר מכן אל ה- Proxy של SIP, וה- Proxy מסיים את השיחה. כדי לפתור בעיה זו, קבע את המקור של הודעת SIP BYE ולאחר מכן פתור את הבעיה במקור.