לקוח של לינגנו עבר למשרד חדש, והתקין שם מרכזיה של Avaya. זוהי מרכזיה שעובדת, בפנים, ב-IP, למרות שרוב התקשורת שלה עם העולם היא באמצעות טלפוניה רגילה. כמות הבעיות שהמרכזיה הזו עושה לנו מרשימה.
דבר ראשון, החברה שמנהלת את המרכזיה לא הפנימה את המושג “אבטחת מידע”, או אפילו “ריכוז מידע”. לפני המעבר התבקשנו לרכז את כל הדברים שנצטרך לעשות לאחריו. לקבל אפילו את רשימת הקופסאות שאנחנו עומדים לקבל לא הצלחנו. אחרי עשרות טלפונים הצלחתי להבין שמדובר בקופסא אחת בשרת שאליה מתחברים ב-PcAnywhere, ועוד תוכנות שרצות על המחשבים של האנשים. בדיעבד הסתבר שאפילו זה לא נכון.
אבל החלק הבאמת קשה היה להבין איפה למקם את המרכזיה. החברה רצתה גישת PcAnywhere למחשב של החברה שמריץ את תוכנת הניהול. כאשר הסברתי ללקוח מה זה אומר, באופן לא מאוד מפתיע, הם סירבו לאפשר גישה לכל הרשת הפנימית שלהם.
טכנאי של החברה ניסה להסביר לי שהמקום ההגיוני היחידי לשים את המרכזיה זה בתוך הרשת הפנימית, משהו שלא הייתי מוכן לעשות בשום פנים ואופן. היום הייתי צריך ממש לצעוק עליו עד שהסכים איתי שזה דווקא כן אפשרי לשים את המרכזיה ברשת נפרדת מאשר תחנות העבודה של האנשים (אני אזכיר לכם – לא מדובר בתוכנה שהיא הטלפון, רק בתוכנה שנותנת שירותים נלווים לטלפוניה!).
אחרי נידנודים מסויימים הצלחתי לקבל רשימת פורטים שמשמשים לתקשורת בין התוכנה למרכזיה, אלא שחצי שניה של הסתכלות הראו לי שזו רשימה לא נכונה. אין שום סיבה שהתוכנה, שלא עושה טלפוניה, תתקשר ב-SIP עם המרכזיה.
אם התמדתם עד כאן, אתם יכולים לטעון, במידה רבה של צדק, שהבעיה היא בחברה שנותנת את השירות בארץ, ולא ב-Avaya עצמם.
בסוף אמרתי לו פשוט לשים את התוכנה על מחשב אחד, ועקבתי אחרי השימוש שלו. הנה מה שהסתבר לי:
כאשר מתקשרים ב-UDP או ב-TCP, יש מספרי “port”. תחשבו על זה ככה. אם כתובת ה-IP משולה למספר טלפון, מספר ה-Port משול למספר שלוחה. למרות שאין ב-UDP כל דרישה מפורשת כזו, נהוג שתקשורת שיוצאת מפורט א’ לפורט ב’ תענה ע”י תקשורת מפורט ב’ לפורט א’. רוב הפיירוולים יודעים את העובדה הזו, ומאפשרים לתקשורת לחזור באותו מסלול.
בפרט, נהוג שרק אחד הצדדים משתמש בפורט ידוע. למשל, אם אני צריך לדבר עם מישהו לפורט 69, אני אקבל פורט בעל מספר אקראי (מתוך מאגר פורטים אקראיים). אם קיבלתי, לדוגמא, את 1231, אני אתקשר בתקשורת שיוצאת מפורט 1231 ומיועדת לפורט 69, והתשובות יגיעו מפורט 69 לפורט 1231. כמו שאמרתי, אם תתנהגו כך, חומת האש תיתן לכם לעבור בזכות הבקשה המקורית שהגיעה לפורט 69.
אלא ש-Avaya לא מאמינים בלנהוג ע”פ מה שמקובל. כל פאקט שהם מוציאים יוצר מכתובת אקראית, וממוען לכתובת שממנה יצאה הבקשה המקורית (שלהזכירכם – גם היא אקראית). במילים אחרות, אין לי שום דבר שאני יכול על פיו להגדיר חוק שיאפשר לתנועה לעבור!
והנה, אחרי שצעקתי וכעסתי על הטכנאי, פתאום הוא הסכים להודות שיש בעיות ידועות, הסכים לבדוק אם הבעיה הזו היא אחת מהן, ובכלל פתאום היה הרבה יותר גמיש בהתנהלות שלו.
מסקנות:
א. להשתמש ב-Asterisk. שם, לפחות, אם מישהו עומד לעשות משהו כל כך טיפשי, אפשר לתקן.
ב. צריך לדעת לצעוק.
שחר
נ.ב.
הפתרון – לאפשר למרכזיה לדבר ב-UDP עם כל מאגר הפורטים האקראיים של כל המכונות ברשת הפנימית. קשה לי לקרוא לפתרון הזה אידאלי, אבל זה הכי טוב שאפשר היה לייצר.
החברה שנותנת את השירות ל-Avaya בארץ היא IBM, לא? או איזשהו אאוטסורסינג שלהם. בתור משתמשת קצה של Avaya (אל תשאל) גם לא התרשמתי לחיוב. מיליון באגים שאף אחד לא טרח לתקן. כל לחיצה על כפתור "השתק", למשל, הייתה מאפסת את זמן השיחה. אולי זו רק האדפטציה שמכרו לחברה שעבדתי בה.
מוזר לי לבוא להגנת תוכנה קניינית, אבל מה לעשות…
1. תוכנת "ניהול" עשויה מאוד לדבר ב- SIP עם המרכזיה להעברת מידע שאינו שיחת טלפון -לדוגמה מידע על presence (האם המשתמש זמין לקבל שיחה עכשיו או הוא לא באמת ליד המחשב כי ה- screen saver שלו דולק).
זה לא אומר שאני יודע שלשם כך התבקשת לפתוח את הפורט הרלוונטי, אבל כן יש סיבה טובה לאפליקציית "ניהול" שאיננה טלפון לדבר SIP.
2. הסידור עם הפורטים הוא באמת בלגן, אבל הוא לא הבלגן של Avaya. לתלונות נא לפנות ל- ITU (ארגון התקינה העולמי של רשתות הטלפוניה) שהגדיר כך את פרוטוקול ה- RTP.
אני משוכנע לחלוטין שיש setting אפישהו במרכזיה להכריח את הפורטים להתנהג בהתאם להגיון והשפיות ולא בהתאם לסטנדרט (יש כזה setting בכל מרכזיית IP שאני מכיר) אבל זה לא אומר שהמתקין יודע את זה.
כל זה לא בא להגיד שהמסקנה שלך לגבי אסטריסק מוטעת, רק שזו לא בדיוק אשמת Avaya.
גלעד
קראתי את טענותיך, ואני נאלץ לדחות אותן אחת לאחת, מהטעמים הבאים:
1. תוכנת הניהול אינה מדברת את הפרוטוקולים הרלוונטיים. המתקין עשה copy-paste מהמקום הלא נכון. הרשימה כללה גם פורטים של H.323. הוא ביקש שאני אפתח כל מה שנראה לו רלוונטי.
2. הפורטים הרלוונטיים הם אכן של RTP. זה לא הפרוטוקול שבו אני מדבר. אני מדבר על TFTP, שהוא למיטב ידיעתי לא משהו שקשור ל-VOIP באיזושהי צורה. כמו כן, למיטב ידיעתי הפרוטוקול ממומש ע"י עשרות תוכנות אחרות ללא בעיה דומה. כל מה שקרה פה זה ש-Avaya התרגלו להתנהגויות לא ידידותיות, ולא טרחו לשנות אותן גם כשהיתה להם הברירה.
לגבי המתקין – בהחלט ייתכן שלמרכזיה יש אופציה כזו. מה שכן, המתקין נשאל הן לגבי המרכזיה והן לגבי התוכנה אם יש, וענה בשלילה.
אני חושש שאני עומד מאחורי הביקורת המקורית שלי.
שחר
יותר הגיוני לדעתי שהבחור שאיתו דיברת פשוט לא מבין שם דבר בנושא.
אמרו לו "תשלח את זה" והוא שלח כי הוא פשוט לא מבין (או שחשבו שאתה תשתכנע ותרפה).
בכל מקרה, מהנסיון שלי – מרכזיות IP עדיין לא בשלות.
הן עדיין עולות פי 5 ממרכזיה רגילה ומלאות בעיות.
ואם הצעקות לא עוזרות, מה לגבי מחבט ביסבול?
אז, זהו. אני יודע איך להכות אנשים עם מחבט בייסבול דרך טלפון רגיל, אבל הוא דיבר איתי דרך מרכזיה שהיתה בשליטתו ושאני לא מכיר…
שחר
ועל צד ההערות חסרות התוכן :
גם לי לצערי יש ניסיון מר ביותר עם Avaya. החל מתיעוד בזוי לחלוטין שלא מאפשר להבין ולו חצי דבר לגבי אופן הפעולה של המרכזיה, נמשיך בהגדרות שמשתנות באופן ספונטני בשרת של המרכזייה, נעבור לקשיים בסביבה של המשתמש בפעולות בסיסיות כגון משיכה או העברת שיחה, ונמשיך לרושם אישי שנוצר אצלי מהתבוננות באופן הפעולה הכולל של המכשיר שהשאיר אצלי טעם של תוכנה סוג ד’. הנציגות של Avaya בארץ לא מוכנה לתת תמיכה, בעוד שידוע להם שיש מספר לא מבוטל של באגים במרכזייה שגורמים ללא מעט אנשים צרות… גם כאן נדרשו צעקות על מנת לגרום להם לזוז… ולא! הבעיות לא נפתרו. הסוף היה שהמרכזיה הוחזרה עם כוונה שלא לשוב לעולם.
טוב יהיה אם תקום חברה שתבנה את אותן המרכזיות כמו של Avaya רק עם Asterisk בפנים. או בדומה למודל של Avaya יישום תוכנה על שרת מארח ביחד עם יישום חומרה בקופסה נפרדת.