קטגוריה: VoIP

סיכום שנה – 2015

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

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

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

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

הגעתי למשל למצב שבו אני יושב עם אנשי מתג של חברת תקשורת מוכרת בישראל, והם צוחקים עלי שאני ילד, כי אני "רק" תשע שנים בתחום התקשורת. כאשר אני התחלתי (ועדיין אפילו לא מתקרב לחיתולים)  ללמוד קצת על SS7 ו SIGTAN עבור אחד הפרויקטים.

פרויקט של גוף ממשלתי שהשורשים שלו נטעו בסוף 2012, הגיע למצב של פיילוט ב2015, שעכשיו ב2016 כנראה שיכנס להיות בכל הארץ אצל אותו גוף ממשלתי.

מספר פרויקטים נוספים גם הם נמצאים בשימוש של מספר גופים בארץ שלהם משתמשים רבים התחיל ב2015 ועכשיו מתחיל להתרחב לשימוש גדול עוד יותר.

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

דברים נוספים שהתחילו ב2013, התפתחו יותר ב2015, כאשר אני מקווה שעד 2017 אוכל כבר להציג ולדבר עליהם בחופשיות יותר, היות והם הולכים לשנות מספר גישות שאנחנו מכירים כיום, במידה ויישארו בכיוון שנכנס כרגע, והיו כמובן משוחררים בקוד פתוח.

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

יש אצלי למה לחכות, ואנסה לעדכן יותר את הבלוג תוך כדי.

אריקסון ו webrtc

כבר כתבתי בעבר על webrtc, אך זה עולם שכל הזמן משתנה ולא רק טכנולוגית.

אחד הדברים שמאוד נחמדים בעולם ה webrtc, זה היענות של מרבית החברות הגדולות בשוק בשביל לאמץ אותו.

גוגל היא החברה הכי מפורסמת שמנסה לקדם את webrtc, ויש לה אתר שהיא פתחה בנושא, והיא משחררת מימוש (בראש ובראשונה נועד עבור כרום) ברישיון MIT.

לעומת זאת, חברה גדולה אחרת גם נכנסה לתמונה, והחליטה שהיא לא סומכת על המימוש של גוגל, והיא יוצרת מימוש עצמאי משלה ל webrtc.

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

החברה פתחה אתר בנושא, ושמה את הקוד שלה ב github, וגם הוא ברישיון פתוח – BSD.
הכלים שהיא משתמשת גם הם פתוחים, כדוגמת Gstreamer .
הם גם משתמשים במימוש של סיסקו – מימוש קוד פתוח עבור H.264, למעשה זה משהו שהם מספקים שגוגל בכלל לא.

הם גם משחררים דפדפן עבור iOS בשם bowser אשר מאפשר בעצם לקבל תמיכה ב webrtc, ובכך הם הופכים להיות הדפדפן הראשון במערכת הפעלה זו שתומך בזה.
הדפדפן נועד לקדם דווקא את H.264, אבל בנתיים גם מאפשר להשתמש ב webrtc.

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

בנתיים גם מיקרוסופט הודיעו בבלוג של סקייפ על התמיכה שלהם ב webrtc, והיכולת לשלב את סקייפ בדפדפן שלה.

כרגע יש קרב גדול על בחירת קודקים לוידאו, כאשר הקרב הוא בין H.264 לבין VP8 ובעתיד גם VP9.

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

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

טלפון חכם, טלפון טיפש

לאחרונה נשאלתי אצל לקוח שאלה מעניינת – מה ההבדל בין טלפון "טיפש" (טלפון "בזק" רגיל) לבין טלפון "חכם" (טלפון SIP) ?
חשבתי לחלוק את התשובה גם כאן.

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

התשובה המסובכת יותר: להמשיך לקרוא

יצאה גרסת 1.4.4 של FreeSwitch

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

המרכזייה בנויה מיחידת בסיס (core) ואוסף מודולים שונים, אשר מספקים לה תכונות שונות, בהתאם לצורת השימוש.
למשל, במידה ומעוניינים ליצור call centre, אז יש מודול לכך, ובמידה ורוצים ליצור ivr בצורה פשוטה, גם לכך יש מודול. אפילו חדרי ועידה מקבלים תכונות רבות יותר מאשר אלו של אסטריסק.
כל ההגדרות כולל ה diallplan נעשות באמצעות קבצי xml, אבל אפילו תוכניות החיוג זה למעשה מודול חיצוני. כאשר מעוניינים בכך, ניתן לצאת לשפות תכנות חיצוניות (גם כמודול), כדוגמת lua (שנתמכת הכי טוב), פרל (לא מתועדת מספיק), פיתון ואפילו ג'אווה סקריפט (יש תמיכה ב v8 ו SpiderMonkey, כאשר האחרון נמצא בשלב deprecated).
בנוסף, יש מימוש של event sockets – אחת הדרכים לשלוט במרכזיה, ולקבל אירועים ממנה, על ידי שימוש בפרוטוקולי תקשורת, כדוגמת TCP. ואלו מאפשרים חיבור של שפות נוספות, כדוגמת Go.
בנוסף, יש גם ספרייה שממשת את rayo – תת פרוטוקול xmpp אשר מאפשר גם שליטה דומה ל event sockets.

אז מדוע אני מציין דווקא את הגרסה הזו על פני כל הגרסאות הקודמות ? ובכן, זו הגרסה הראשונה של סדרת 1.4, אשר נחשבת לגרסה יציבה, ולא גרסת Beta. כלומר זו גרסה רשמית יציבה ראשונה של העץ 1.4.

עץ 1.4 הביא איתו המון חידושים ושיפורי ביצועים, בהם בראש ובראשונה תמיכה מלאה בתקני webrtc ו websockets, אשר מניסיון שלי, טובים יותר מהתמיכה שיש באסטריסק. נכון לכתיבת שורות אלו, כרום ביטל את התמיכה ב SDES, דבר שמקשה על התמיכה ב webrtc של אסטריסק ללא בנייה אישית שלו, בעוד שFreeSwitch תומך ב dtls-srtp ללא בעיה מהקופסא.

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

כרגע עץ 1.2, אשר נחשב ליציב, עבר להיות גרסת LTS, אשר מקבלת רק עדכוני אבטחה, ותיקוני באגים גורליים, אך לא מעבר.

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

העניין החשוב באמת הוא, ש FreeSwitch מספקת את האפשרות לקבל מרכזייה יציבה, שמשתמת יחסית במעט משאבים (תלוי באופן השימוש), עם המון יכולות.
היא יכולה להיות למעשה מרכזייה ברמת class 4 ולא רק class 5 בניגוד לאסטריסק למשל. ועץ 1.4 מבטיח כניסה לעולמות חדשים.

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

סיפ, מדוע זה לא פשוט כמו HTTP ?

אחד התסכולים הרבים שיש בעולם ה VoIP הוא התמודדות עם בעיות הקשורות לעולם הרשתות.

רוב העולם בטוח כי HTTP זו התקשורת המסובכת ביותר שיש בעולם הרשתות, ולכן אני שומע את השאלה: "אני לא מבין למה SIP לא פשוט כמו HTTP ?"

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

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

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

על זה נוסיף עוד בעיה "נחמדה" אשר נקראת NAT, כאשר ישנם 2 סוגי NAT: להמשיך לקרוא

הגדרת sip trunk עם freeswitch

freeswitch שונה מאוד מאסטריסק בתפיסה של איך דברים עובדים.
במידה ונרצה להוציא שיחות או להכניס שיחות, אין צורך בהגדרות מיוחדות, למעט הגדרות acl לכתובות ip. כלומר בברירת מחדל אין צורך ככה סתם להגדיר sip trunk בשביל שדברים יפעלו עבור ספק מסויים.

אך במידה ויש צורך להגדרות מיוחדות, או הגדרות של ביצוע פעולת register, אז אנחנו זקוקים להגדיר sip trunk, אך גם שם ישנם 2 גישות, אשר מוגדרות תחת sip_profiles:

  1. internal
  2. external

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

בברירת המחדל, internal מוגדר להשתמש עם sip בפורטים של 5060 ו 5061 (אם זה sip או sips). בעוד שרשת external מוגדר בברירת המחדל להשתמש בפורטים 5080 ו5081.

השאלה הנזרקת לאוויר, היא מה קורה כאשר הרשת החיצונית נכנסת דרך 5060, והתשובה היא שfreeswitch מכניס ל header בקשה לעבור ל5080, ובמידת האפשר מעביר את התקשורת לשם, ואם לא, אז נשארים על 5060, אבל היא לא נחשבת לרשת trusted.

העניין הוא, שזה לא נעצר בפורטים, או בהפרדה הזו, אלא זה ממש מסייע למפות מההתחלה עד הסוף מאיפה השיחה מגיעה. האם היא נכנסת מרשת internal או external (למשל), ובכך גם להתנהג לגמרי שונה ולהיכנס ל context לגמרי שונים (כפי שמוגדר בברירת המחדל).
כך למשל, אפשר להגדיר טלפונים (מכשירי טלפון, להבדיל משלוחות המוגדרות ב directory) ב internal בעוד ש sip trunk (או gateway כשם נוסף) לספקית חיצונית נגדיר ב external. להמשיך לקרוא

מרכזיה או פרוקסי, על רגל אחת

פוסט זה הוא שכתוב רביעי של הנושא, בתקווה שהוא יהיה ברור לאנשים טכניים לא מעולם הVoIP.

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

המרכזיה אשר כולם עובדים איתה, אך שקופה מאוד עבור הרבה נקראת מרכזייה class 4. זו מרכזיה אשר מעבירה תעבורה מצד אחד לצד שני.

מרכזייה סוג 3 (class 3) שהיא בעצם מרכזייה איזורית. וכמובן שזה יורד ככה עד לclass 1.

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

  1. שרת אותות (signals)
  2. שרת מדיה (media)

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

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

שרתי פרוקסי יודעים לנתב ולנתח שיחה, לאפשר או לא לאפשר הרשאות שונות, וכן לבצע חיובים שונים על השיחה. אך הם אינם מצב קצה של השיחה, כי אם מצב אמצע, כדוגמת נתב בתקשורת רגילה. אין לה שלוחות, היא לא מנהלת פעולות קצה של משתמשים, אלא רק יודעת לנתח שיחה על מגוון הדברים שלה, ולהחליט אם להמשיך איתה הלאה, ואם כן לאן, או להפיל אותה לפי הצרכים של השרת (UAS – Userver Agent Server), וכן הצרכים של הלקוח (UAC – User Agent Client).
פרוקסי לרוב מקבל את התאור של B2BUA. כלומר לנתח תעבורה ולהחליט מה קורה איתה, כאילו היה UAS.

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

זה על רגל אחת הנושא בניסיון להסביר את ההבדלים של השניים.

הבנה של bindaddr באסטריסק

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

Serious Network Trouble; __sip_xmit returns error for pkt data

בד"כ במצב כזה, החשד הוא שמשהו אחר תופס את הפורט, אז הרצתי בדיקה של netstat ואפילו lsof, וכלום, הפורט פנוי.
הרצתי netcat כשרת, והוא הצליח ללא בעיה לבצע bind על הפורט הזה.

הבעיה היא, שהלקוח עובד עם elastix שמבוססת על freepbx, וזו מתערבת בקבצי ההגדרות, ויוצרת עוד קבצי הגדרות חדשים עבורך להוספה, ולא ניתן לשנות קבצי הגדרות ידנית, כי היא דורסת אותם, אלא אם אלו קבצי "‎‎_custom.conf"
לאחר המון שעות מחקר, החלטתי לגשת לקבצים שנוצרים אוטומטית, וגיליתי כי bindaddr הצביע על כתובת IP שאומנם חוקית ברשת של המרכזיה, אבל היא לא שייכת למכונה.

כאן צריך להיכנס ולהבין בעצם את אסטריסק יותר לעומק.
במצב רגיל, כאשר פותחים socket ניתן להגיד לו להאזין לכתובת ip מסויימת, במקום להאזין להכל.
אבל באסטריסק ביצוע bind הוא מעט שונה בתפיסה שלו.
באסטריסק, הכתובת ip היא כתובת שקשורה לניתוב. היא אומרת לאסטריסק מאיפה התקשורת תגיע ולאן היא צריכה ללכת. לא ברמה של כתובת שרת, אלא ברמה של כרטיס רשת. כך שאם כתובת הip אינה שייכת לnetwork device, אסטריסק אינו יכול "להינעל" על אותה כתובת ip, שכן זו בעצם היכולת שלו לבצע bind על כרטיס רשת ולכן הוא אינו יכול להאזין לדברים.

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

עם אותו לקוח, הסתבר כי הוא התקין תוסף ל FreePBX שמאפשר לו בצורה גרפית להגדיר את הכתובת, דבר שמוגדר בקובץ שנוצר אוטומטית, ולי אין יכולת להתערב בתוכן שלו בלי שזה ידרס.
הוא הגדיר את הכתובת החיצונית של הרשת שלו (כאשר הוא מאחורי nat), ולא את כתובת המרכזיה עצמה, וכאשר העברתי את זה ל 0.0.0.0 הבעיה נפתרה לה, לאחר שלוש שעות של מחקר להבין מדוע אסטריסק לא ביצע bind לכתובת.

רשומות DNS עבור SIP

לפני מספר שנים, למדתי הרבה (אך לא הכל 😦 ) על עולם ה DNS ובעיקר עבודה עם Bind, אך מצאתי שבד"כ יש רק מספר מצומצם של רשומות אשר משתמשים בהם: A, CNAME, TXT ו MX.
לאחרונה יצא לי ליעץ למספר חברות שונות אשר רצו לספק יותר משרת אחד לשירות SIP, ומצאתי את עצמי עושה להם קורס מזורז (לרוב דרך דוא"ל ושיחות טלפון) כיצד זה מתבצע, אז החלטתי להעביר את זה לכתב, ולנסות ולסייע יותר לאנשים באופן כללי.

A/AAAA

רשומת A מייצגת בעצם שם מתחם עבור כתובת IP. יש לו אח צעיר יותר בשם AAAA אשר מבצע אותו הדבר, רק עבור כתובות IPv6.

CNAME

רשומת CNAME, יודעת לקחת שם מתחם קיים, ולתת לו alias לשם אחר, כלומר foo.example.com יכול גם להצביע על bar.example.com ובכך שניהם מצביעים לאותו הדבר. הפירוש של CNAME הוא canonical name record והוא מעט "ממזר" באיך שקוראים ומשתמשים ברשומה.

TXT

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

MX

ויש את רשומת MX, אשר היא קיצור של mail exchanger record. התפקיד של הרשומה הוא לספק גישה למספר שרתי דואר תחת שם מתחם בודד, כאשר יש "משקל" לכל כתובת. המשקל אומר על קדימות של שימוש בשרת אחד על גבי השני. ככול שהמספר גבוהה יותר, כך כמות השימוש בו תהיה גבוהה יותר. כך שאם אשים משקל 60 לכתובת אחת ו10 לכתובת שניה, אז על כל 60 פניות לכתובת הראשונה, יהיו עשר פניות לכתובת השניה.

SOA

עוד רשומה מאוד נפוצה (למעשה הנפוצה ביותר) היא SOA שהיא Source of Authority. היא מחליטה בעצם על מי מנהל את ה DNS בפועל, או כמו שחבר כנסת חיפש פעם, הוא פחות או יותר האחראי על האינטרנט, לפחות בנושא של שמות מתחם.

כל זה נחמד למרבית השימוש כיום באינטרנט, אבל יש למעשה כמה עשרות סוגים של רשומות DNS, ועבור SIP אנחנו צריכים להשתמש בדרך כלל ברשומה מסוג SRV אשר משתמשת דרכה בכתובת שהיא A/CNAME . להמשיך לקרוא

where have all the music gone ?

I used to be a Pandora user, but due to issues with the Music labelling cartel, it was forced to close it's service outside of the U.S. Australia and New-Zealand.
So I moved to Last.fm that offered me to pay a fee and listen to music. Until I got the following Email: להמשיך לקרוא

הבנת אבטחת מידע בנוגע ל SIP

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

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

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

נתחיל מהסוף. SIP הוא פרוטוקול Voice Over IP אשר אומר כי הוא מעביר מידע אודות השיחה וההתנהלות שלה מצד אחד לצד שני, אבל הוא לא אחראי למה שקורה בשיחה, אלא רק למידע שמנסה ליצור את השיחה ומה מתרחש בשיחה. כלומר הוא מעביר אותות שונים אודות השיחה בלבד (משהו בסגנון של צליל חיוג, תפוס, לא זמין וכו' לאנשים הפחות טכניים שקוראים את הפוסט).

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

אז איך כן אפשר להגן על SIP ?

דבר ראשון תעשו סיסמה חזקה ומיוחדת לשלוחה שלכם.

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

מAsterisk גרסה 1.8, אפשר להשתמש במנהרת SSL להצפנה, אבל זה תלוי גם בתמיכה של הטלפוני SIP בצד השני, ואם הם תומכים בגישה הזו. אבל זה לא פותר את בעיית הגניבה, אלא רק את בעיית "אדם באמצע" (Man In the middle), אשר לא יוכל להאזין למה שקורה, אבל כן לנסות ליצור שיחות בעצמו ולהתחבר בעצמו.

עוד דרך היא לעבוד עם VPN מאובטח. הבעיה היא ש iPhone ללא פריצה אינו מסוגל לעשות דבר כזה למעט SSL VPN של חברת fortigate (אשמח לגלות שאפל מאשרים ליותר vpn מאובטחים לעבוד על הצעצוע שלהם), וAndroid דורש גישת root להתקנה של מרבית ה VPN כדוגמת openvpn, כך שצריך אנשים טכניים בשביל לגרום לדברים לעבוד, ומשתמש "פשוט" שלא רוצה להבין טכנולוגיה ולא רוצה לשנות את דרכיו ורק רוצה שהכל יעבוד בשבילו לא יכול לקבל כלום.

עוד דרך, אשר לא תמנע Man In the Middle אבל תגן על המרכזייה שלכם מגניבת שיחות היא שימוש בכתובת IP קבועה. אז מה עושים אנשים עם כתובת מ DHCP או מבית קפה ? ובכן תמצאו מקום טוב יותר להיות בו, או שתעבדו עם VPN, כל כך "פשוט".

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

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

בעיית אבטחה לוגית באסטריסק

התגלתה לאחרונה בעיית אבטחה מאוד מעניינת באסטריסק. בניגוד לבעיות "רגילות" של קוד, כאן מדובר בבעיה של לוגיקה אשר יכולה לגרום לבעיה מאוד קשה.

הבעיה היא מאוד פשוטה לתאור, ומאוד לא פשוטה לפתרון.

במידה ויש לי בתכנית החיוג דבר כזה:

exten => _X.,n,Dial(SIP/${EXTEN})

אז אני יכול להזריק למשתנה EXTEN ערכים שאני רוצה שהוא יכיל, לדוגמא (איך זה יראה אחרי תרגום המשתנה):

exten => _X.,n,Dial(SIP/123@context&SIP/0123456789@anothercontext&DAHADI/g1/03123456789@anothercontext)

ואז במקום שהתכנית תחייג רק ל 123 בפרוטוקול SIP היא תחייג גם ל SIP עם המספר 123456789 וגם תצא לכרטיס טלפוניה בקבוצה 1 עם המספר 03123456789 ובכך הזרקנו עוד מספרים לחיוג.

אבל זה לא הכול, אפשר להזריק כל דבר שרוצים, כך שאפשר לתת הרשאות או הגדרות ל Dial אשר המשתמש הרגיל לא צריך לבצע.

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

כמו כן, לא בכל מדינה/סוג שירות יש אורך קבוע של ספרות. יש ארצות בהם האורך משתנה, ולכן אי אפשר לתת מענה הולם, לבעיה.

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

יש כמה דרכים כרגע להתמודד כבר עכשיו עם הבעיה, כדוגמת השימוש ב FILTER כמומלץ בפוסט שאליו קישרתי למעלה שלדעתי האישית הפתרון הטוב והקל ביותר לביצוע בשלב זה.

ההודעה המקורית ברשימת הדיוור.

אריזה מדהימה לרעיון ישן

הייתי היום בVON. אחד מהמיצגים שם (וכן ההרצאות) היו של חברת מיקרוסופט.

מיקרוסופט נכנסת לעולם ה VoIP עם איזה סוג PBX בשם Communicator. הPBX מבוסס SIP [תקן פתוח ויש סיבה לזה שתכף אכנס אליה].

להמשיך לקרוא

מתי לא לבחור מערכת קוד סגור

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

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

בכל מקרה, אני עובד עם קובונטו 7.04 בסביבת 64 סיביות. Skype מגיע רק ב32 סיביות דבר שגורם לכך שצריך לשחק קצת עם המערכת בשביל לגרום לו לעבוד, כל עוד כל החבילות שזקוקה התוכנה קיימות. זו ד"א הסיבה שאני לא יכול לשדרג לגרסה חדשה יותר של סקייפ הדורשת ספריות אשר אין להם גרסת הספריות איתם אני יכול להשתמש.

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

למי שאינו יודע, יש פתרונות טובים יותר כדוגמת Asterisk אשר יתן לי את היכולת לדבר ב VoIP. הפתרון גם דורש Softphone – כלומר טלפון תוכנה. הכול מגיע עם רשיונות קוד פתוח.
אני חושב שSkype הוכיחה פעם נוספת כי לא ניתן באמת לסמוך על השירות שהיא נותנת כאשר מדובר בעולם העסקי, והגיע הזמן לעבור לשירותים טובים יותר מזה.

VON 2007 ישראל

ביום ראשון הקרוב ה14 לחודש יתקיים בקרית שדה התעופה אשר מוכרת לנו גם בשם Airport city אירוע בין לאומי לתקשורת וטלפוניה הנקרא VON.

בVON מציגים טכנולוגיות VoIP למינהם בנוסף להרצאות וכו'..

כמו בכל שנה, גם השנה ג'ף פולבר ישתתף בכנס.

מי שאינו מכיר את ג'ף, מוזמן לקרוא עליו.

פיתוח מהיר וקל

לפני יומיים התקנתי (גם אני) את FPC 2.2.0. וכרגיל בניתי אחרי עדכון עוד גרסה של Lazarus ישירות מה svn. גרסת ה QT4 שאני לאחרונה ערכתי עליה ניסויים עדיין רחוקה מלספק לי כלי נורמלי לפיתוח (ואני באמת מצר על כך).
אז החלטתי לנסות אחרי התעלמות רבת החודשים, שוב את GTK 2 בלזרוס. חשוב לי להזכיר כי יום לפני שחרור FPC 2.2.0 ניסיתי את גרסת GKT2 של לזרוס שקרסה בזמן עליית הIDE.
אבל פתאום על אותה גרסת SVN לתדהמתי Lazarus פשוט עובדת. ועובדת די טוב יחסית לגרסה לא יציבה ולא מושלמת (וכן היא עדיין מכילה הרבה באגים).
עכשיו הצלחתי להשלים את משימת פיתוח ה FastAGI שלי (שנכון לזמן כתיבת הבלוג, נשאר לי רק להתחיל לשלוח פקודות ולקבל את התשובה חזרה). פשוט מדהים.
Lazarus, GTK2, Hebrew

לדעתי כיום Lazarus היא הסביבת פיתוח הכי מהירה ופשוטה לפתח תוכנות תחת GTK2. היות ו Lazarus "מכילה" גם את Glade וגם את הרעיון של pyGTK בייחד, זה עניין של דקות בודדות עד שתהיה לך סביבת GTK פשוטה וגרפית עם הקוד שאתה רוצה. פשוט מדהים.

הדגמה לניצול בעיית אבטחה של טלפון תוכנה

השנה בכנס BlackHat בלאס ווגס היתה הדגמה של בעיית אבטחה בעולם ה VoIP, וכן על כמה פתרונות אבטחה בעולם.
הרבה מרכזיות VoIP אינן מוגנות, היות וארגונים בטוחים כי כל מה שצריך זה להשאיר את השרת תחת חומת אש או משהו כזה, אין תמיד דגש על אבטחה, ועל הרשאות גישה וכו'.

האתר Blue Box שם לו לדגש להציג בעיות אבטחת מידע בעולם הVoIP באמצעות שידורי PodCast.

אחד משידורי הPodCast מציג הדגמה של בעיית אבטחה בטלפון תוכנה הרץ בWindows. הפירצה מאפשרת ניצול של באג, ונותנת גישה ישירה לShell ב Windows.

ניהול קוד בלינוקס

לאחרונה יצא לי לכתוב ספריות עבודה עבור Asterisk כדוגמת ביצוע AGI ו FastAGI גם בשבילי וגם בשביל להחזיר חזרה לקהילה.

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

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

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

אבל כרגע אני צריך לקחת קוד קיים ולהעביר אותו מ2 מחלקות קיימות למחלקה אחת (מרבית הקוד, אבל לא את כולו), אבל בשביל להצליח לעשות את המשימה, אני זקוק להשתמש בעורכי הטקסט הרגילים בלינוקס, אשר גורמים לי לקפוץ בין הרבה שורות וכו'… דבר שגורם לך לפספס הרבה דברים, ולבעיות. העניין הוא שvim למרות שהתאמתי לו את הצביעה לתחביר המתקדם של פסקל, עדיין חסרים לו כמה מילים שמורות (וזה עוד בלי לדבר על תחביר חדש יותר כדוגמת התחביר של Generics אשר אין לי מושג כרגע כיצד להוסיף ל vim). ואחרי שבוע כמעט של שגיאות ממש מטופשות (וחזרה לקוד של לפני הניסיון לשינויים), אני מחפש צורה טובה יותר לנהל את הקוד שלי, כולל אפשרות ממש טובה לצביעה של קוד פסקל מונחה עצמים מתקדם של FPC. וגם האפשרות לפצל קובץ ליותר ממקום אחד כמו שvim נותן, ושיהיה מהיר ויציב.

האם אתם מכירים עורך טקסט (ולא סביבת עבודה משולבת) בלינוקס היכול לענות על הדרישות המסובכות שלי ?

משחק המונופול של המשק הישראלי

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

להמשיך לקרוא