איכות שיחה בענן בישראל - אין MoS, לא קונה!
מאת: ניר סמיונוביץ, 30.3.17, 09:41
 
על האמת העגומה של שירותי טלפוניה בענן בארץ. מהם 3 מרכיבי מדד איכות השיחה? מה זה MoS? האם יש שירותי מדידה בענן?
 
האמת העגומה של שירותי טלפוניה בענן בישראל היא מאוד פשוטה. איכות השיחה במקרים רבים היא ירודה לחלוטין. מדוע האיכות ירודה? פשוט מאוד, הלקוחות לא ממש יודעים מה לדרוש, ויותר גרוע מזה, הם גם לא יודעים איך למדוד את איכות השיחה בצורה אבסולוטית.
 
לאיכות שיחה יש מדד ידוע, והוא מכיל התייחסות ל-3 מרכיבים עיקריים: Packet Loss, Latency ו-Jitter. כמו כן, מעבר לנושאים אלה, יש את המדד המשוקלל הנקרא MoS – Mean Opinion Score, שניתן לפרש אותו ולחשב אותו בכל מיני צורות. אולם, התוצאה הסופית היא לרוב אותה התוצאה.
 
מה זה Packet Loss?
ההגדרה הבסיסית ביותר במקרה זה תהיה ״איבוד נתונים״. כלומר, מצב בו חלק מסוים מחתיכות המידע שנשלחות פשוט הולכות לאיבוד. נושא ה-Packet Loss הוא מאוד רגיש בעולם ה-VoIP, בעיקר בגלל טבע השידור, שהוא מבוסס על UDP. כלומר, אם איבדנו חתיכת מידע מסוימת, לחזור אחורה ולשחזר אותה זה בלתי אפשרי, כי הפרוטוקול לוקח בחשבון, שמידע יכול (וסביר להניח שיקרה) ילך לו לאיבוד במבוך האינטרנט.
 
מה זה Jitter?
אחת הבעיות העמוקות ביותר של רשתות משרדיות בימינו הוא ה-Jitter. בניגוד ל-,Packet Loss שיחסית קל למדוד אותו ע"י שימוש ב-Ping (וזו לא ממש בדיקה אמינה במיוחד), ה-Jitter מכניס לתווך התקשורת שלנו אלמנט לא ידוע של קפיצות. הקפיצות יכולות להתבטא באיטיות, שבאה והולכת, Ping Latency המשתנה כל הזמן ואיננו קבוע ושאר בעיות הגורמות למידע להגיע ליעדו בתזמונים שונים ומשונים. בעוד ש-Packet Loss הוא משהו, שקשה מאוד להתמודד אתו, עם Jitter לרוב מתמודדים בעזרת מנגנוני Jitter Buffer בציודי הקצה. אולם, אלה כמובן מכניסים שיהוי בשיחה. ואז מתחילות תלונות בסגנון: ״אני שומע אותו שניה וחצי אחרי!״.
 
מה זה Latency?
אין מה לעשות, רשתות התקשורת בעולם לא תמיד מחוברות בסיבים אופטיים מקצה לקצה, ותמיד יהיה לנו Latency מסוים. חלקו בלתי נפרד מתשתית התקשורת, כלומר, אם בין צד א׳ לצד ב׳ יש Latency של 250ms אין הרבה מה לעשות, יהיה לנו שיהוי של רבע שניה בקול. אם נוסיף לזה גם Packet Loss וגם Jitter, והרי לנו מתכון ברור לאיכות קול ירודה.
 
מה זה MoS?
ה-MoS הוא מספר משוקלל, שלוקח בחשבון מדידות של האלמנטים המופיעים מעלה, על פני כל זמן השיחה (מדידה מתבצעת כל 5 שניות), ועי"כ, נותן לשיחה ציון איכותי. יש לשים לב למילה Opinion בתוך המדד, כלומר, כל מערכת יכולה לחשב את זה קצת אחרת. אבל, יחד עם זאת, הנוסחאות מפיקות מידע, שברוב המקרים, דומה מאוד. מדד ה-MoS לרוב נע בין 0 (שיחה שלא התקיימה או איכות שיחה ירודה ביותר), לבין ציון של 4.4 (איכות שיחה מצוינת). שיחה באיכות טובה, תחשב כזו שציונה עומד בין 3.6 ומעלה. ציון בין 2.5 לבין 3.6 יחשב כאיכות סבירה, מתחת לזה כבר צריך להבין מה גרם לאיכות הירודה יחסית. ציון מתחת ל-2 אומר שיחה ירודה ביותר.

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

 
המסך המופיע מעלה לקוח מתוך מערכת Homer SIP Capture בא אנו משתמשים לניטור ענן השירותים שלנו. הקו הכחול מציין את ה-Jitter ממכשיר קצה אל שרת המדיה, הקו הירוק מציין את המסלול חזרה.
 
ניתן להבחין, שיש הפרעה מהותית בשידור ממכשיר הקצה, וכמו כן, יש הפרעות רגעיות בקליטה במכשיר הקצה. אם נבחן את נתוני השיחה מצד שמאל נראה, שה-Jitter הממוצע עומד על 495ms, שזה אומר, שעליו לשהות כל חלקיק מידע לפחות 800ms כדי שנוכל להרכיב את הקול חזרה בצורה תקינה.
 
שימו לב לאחוז ה-Packet Loss - 0.2%, כלומר, כמעט ואין. יש לשים לב, שיש הבדל מהותי בין Packet Loss של Ping, לבין Packet Loss של RTP. בדיקת Ping במקרה של 0.2% תראה 0% כישלון. מבחינת RTP, 0.2% אומר, שהיה פה איבוד מידע, כיוון שהשידור הוא רציף בזמן, והוא הרבה יותר מהיר משידור של Ping.
ציון ה-MoS הממוצע לשיחה זו הוא 1.31. כלומר, שיחה גרועה למדי. האמת, מי שהיו מעורבים בשיחה הזו זה אני ולקוח מקנדה, והשיחה יצאה ממכשיר הקצה שלו, וזה היה נוראי. לאחר בדיקה בצד הלקוח התברר, שבגלל מבנה ה-WiFi שלו, המכשיר קצה קיפץ כל 30 שניות בין Access Points מסיבה בלתי ברורה, וזה גרם לבעיות ה-Jitter, שאנו רואים פה.
 
דוגמא לשיחה באיכות טובה
שוב, ניקח דוגמא מענן השירותים שלנו והפעם לשיחה באיכות טובה. כפי שתשימו לב, המדדים פה נראים שונה לחלוטין. עבור שיחה באורך של 2 דקות ו-45 שניות, איבדנו רק 4 Packets, שזה מספר מעולה. ה-Jitter הממוצע היה על 141ms, כלומר, היה לנו שיהוי בקול, שאיננו עולה על 250ms. וכמובן, ציון ה-MoS הממוצע שלנו עומד על 3.72, שמציין איכות שיחה טובה.
 
האם המדדים המופיעים מעלה אבסולוטיים? בגדול התשובה היא לא, אך אפשר להתייחס אליהם ככאלה. הסיבה העקרונית היא, שמדידות כאלו אפשריות רק כאשר אנו שולטים בתווך השידור ותווך הקליטה בצורה מוחלטת. כל המדדים מופקים ע"י שימוש בפרוטוקול הנקרא RTCP,  RTP Control Protocol, שמעביר לנו נתוני מדדים כל 5 שניות. הבעיה העקרונית היא, שמרבית הספקים הקטנים לא מפעילים מערכות RTCP, כי זה פשוט לא באינטרס שלהם או בגלל שהמערכות שלהם כל כך זולות, שאין להן את היכולת הזו. מיותר לציין, שכל מערכת מבוססת קוד פתוח (Asterisk, FreeSwitch, Yate, SEMS) תומכת בתקן זה כחלק אינטגרלי, והן מספקות את המידע הזה. גם מכשירי הקצה למיניהם מספקים את המידע המופיע מעלה, אך יש להפעיל את זה בצורה יזומה, ולפעמים זה לא כל כך פשוט.
 
האם יש שירותי מדידה בענן?
כן. לפרויקט ה-Homer SIP Capture יש אח גדול יותר הנקרא sipcapture.io. לפרויקט הרלוונטי הזה יש גם נגיעה ישראלית, שכן שלומי גוטמן (שטרודל/Voicenter) מעורב בפרויקט, ושירות הענן הישראלי Voicenter עושה שימוש בתשתיות אלו בצורה מעמיקה.
   
בעוד שהשירות מעולה לגדלים קטנים (משרד של עד 50 איש), במקרה של מוקדי שירות מעל 50 איש, השירות הופך להיות קצת יקר. מחשב וירטואלי בענן ציבורי, שיעשה את אותה העבודה, יעלה כ-80 דולרים לחודש, בעוד בשירות הענן העלות תהיה כ-150 אירו לחודש.
 
בגדול, 2 האפשרויות מצוינות, ואני מאמין, שכל עסק, שיש בו טלפוניה אמינה, היא עמוד טווח של העסק - אפשרות הניטור היא לא Nice to Have אלא Must.
 
ב-GreenfieldTech התחלנו להשתמש ב-Homer SIP Capture ב-2013, וכיום אנו פורסים אותו בכל מערכת מותקנת שלנו. עם השנים למדנו, שהכלי מאפשר ניתוח תקלות מהיר מאוד, אפשרות התמודדות מול ספקי שירותים בצורה טובה, מונע ויכוחים מיותרים בין לקוח לספק שירות על תקלות ועובדות בשטח, והכי חשוב, מספק כלי תפעולי מהדרגה הראשונה לכל מחלקת IT, שצריכה לנהל מערכת VoIP זו או אחרת.
 
למעוניינים, בחודש מאי הקרוב, נערוך מפגש VoIP On Tap שיהיה כולו מוקדש לנושא ניטור מערכות VoIP, מדידת איכויות שיחה, איך מבצעים Forensic לשיחות לא טובות וכיצד להשתמש במערכות מסוג זה, כדי לקבל שירות טוב יותר מספקי התקשורת שלנו.

מאת: ניר סמיונוביץ,  מרץ 2017.
מנכ"ל  GreenfieldTech 
www.greenfieldtech.net
nirs@greenfieldtech.net