בעיות חוזרות בקו SIP של בזק בינלאומי - אולי מישהו מבין בזה לעומק

[oferlap]

מתאם שיחות ותיק מסוג MP-202, מחובר אצלי כמובן *אחרי* הראוטר הפרטי, כי יש דברים חשובים יותר מטלפון קוי מצ'וקמק.
עד לא מזמן, הראוטר היה TP Link Archer VR600 עם אופציה עלומה בשם SIP Passthrough ו- DMZ, והקו עבד כמעט תמיד יפה מאד, באמינות כמעט שקולה לשל קו בזק, למעט T.38 (פקס) שפשוט אף פעם לא עבד.
כעת הראוטר הוא Draytek Vigor 2862L, יותר עשיר באפשרויות, יותר מסובך לקינפוג, ו... הקו עושה מדי פעם בעיות, עד כדי כך שזה ממש רולטה להוציא ולהכניס ממנו שיחות תקינות. אבל- T.38 הפעם כן עובד.

עשיתי Mirror Port ועקבתי אחרי התקשורת למתאם וממנו. הבעיות שקורות מדי פעם:
1) בתגובה ל- Request: INVITE (בקשת חיוג) מהמתאם, השרת, שכתובתו הקבועה היא voipsip.bezeqint.net, עונה 403 Forbidden. זה נוטה לקרות בעיקר כשמבצעים חיוג בדקות שאחרי Restart לראוטר. כשזה קורה, נשמע צליל חיוג לכאורה תקין, אבל בסיום החיוג מתקבל צליל שגיאה, וגם לא ניתן לקבל שיחות. אני חושב שזה בדרך כלל מסתדר מעצמו אחרי זמן מה, אבל נסיונות חיוג חוזרים למספרים *שונים*, נוטים ללא ספק לסיים את השלב הזה מהר יותר.

2) בתגובה ל- Request: REGISTER מהמתאם, השרת עונה 401 Unauthorized,
אבל בנסיון שני שנעשה אוטומטית, השרת מסכים: Status: 200 OK (4 bindings). אלא שגם במצב הזה, לא תמיד ניתן לקבל שיחות, לא תמיד הטלפון מצלצל, למרות שהפורטים הרלוונטיים פתוחים ואני רואה את המתאם מקבל בינתיים פה ושם כל מיני פינגים מרשתות לא קשורות בחו"ל, וזורק אותם עם Host unreachable (אני עוד לא בטוח מה אפשר לחסום ממנו ומה לא, קודם שיעבוד כמו שצריך).

3) לאחר שהרישום עבר, בתגובה לחיוג (Request: INVITE), השרת לפעמים עונה Status: 100 Trying ואז מסרב עם 401 Unauthorized. בנסיון נוסףי, השרת דווקא מסכים לחייג: Status: 200 OK (2 bindings).אבל גם אז הטלפון לא בהכרח מצלצל כשנכנסות שיחות.

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

[fLy]

שווה בדיקה:

http://www.surevoip.co.uk/support/wiki/ ... ytek_3.8.5

[sys_admin]

מה שאתה חווה, זו תוצאה של מימוש עקום של NAT שקיים לרוב בנתבים ביתיים. בחלקם ניתן לבחור את שיטת מימוש שלו. למשל כמו Full Cone NAT או את Symmetric NAT ואחרים. ככלל, פרוטוקול SIP לא סובל את NAT גם בחלק של sip signaling וגם בחלק של sip media. לרוב פיתרון ההיגיוני, הוא בזה שעד ציוד קצה ( IPHPONE או עד ל ATA FXS ) יהיה קיים ערוץ VPN כזה שמקשר את ציוד קצה לרשת הפרטית של המרכזייה. אופציות אחרות הם SIP Proxy בנתב שמבצע את NAT ושנותן ללקוח SIP להירשם בצורה תקינה. אופצייה פחות מומלצת היא שימוש ב STUN Server של ספק טלפונייה שלך. זו אפשרות שמאפשרת את sip nat traversal ברמה מסיימת. ועוד אפשרות היא שימוש בנתב סביר יותר, כמו ב PFSense , ששאלת עליו כאן לפני זמן מה.

[oferlap]

שווה בדיקה:

http://www.surevoip.co.uk/support/wiki/ ... ytek_3.8.5

...

·

תודה על התגובות, אכן כבר גיגלתי בנוגע לפיצ'ר הזה וראיתי שיש - ובצדק - קונצנזוס לבטל אותו. הבעיות שתיארתי הופיעו אצלי כשהוא כבר מבוטל, אחרת מתקבל 403 Forbidden ורק בנס אפשר להוציא בכלל איזו שיחה.
טיפ למי שרוצה לבצע את זה כמו שצריך: בניגוד למה שרשום שם בקישור, לא מספיק לבטל רק את ה- Checkbox הראשי (Enable ALG), זה לא באמת מבטל, גם לא אחרי REstart לראוטר. מוכרחים לבטל קודם בנפרד את הפיצ'ר עבור כל אחד מהפרוטוקולים SIP ו- RSTP, לבצע restart ורק אז לבטל את Enable ALG.


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

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

SIp Proxy אין לי בראוטר הזה.

בסופו של דבר נראה לי שפתרתי את הבעיה. הלכתי בכיוון שנתת שהבעיה היא ב- NAT, ומצאתי בראוטר אפשרות להגדיר Route Policies. הגדרתי שם לתת עדיפות עליונה לתקשורת ממתאם השיחות אל השרת של המרכזיה וממנו למתאם (האפשרויות הן בין 0 ל- 250 וברירת המחדל היא 150), הגדרתי גם דרך איזה חיבור WAN זה מוכרח להתבצע (כי הנתב מתמרן בעקרון בין חיבור VDSL לסלולרי) - ונכון לעכשיו, אחרי המון נסיונות מוצלחים נראה שהכל עובד ללא שום שגיאות.
אני עדיין לא מבין למה ההגדרות של Qos שחשבתי שאמורות לבצע בדיוק את אותה פעולה של מתן עדיפות והקטנת Latency למינימום , לא עזרו כמעט בכלל.

[amdr1]

תשתית הוט או בזק?

[oferlap]

@amdr1
·
תשתית כפולה: VDSL2 של בזק (ספק בזק בינלאומי) ו- LTE של גולן טלקום. אבל ה- LTE לא רלוונטי לטלפוניה בגלל ה-NAT הכפול שכל חברות הסלולר נותנות, וכנראה גם מעוד סיבות כמו jitter גבוה ופינגים גבוהים. ייתכן שהבעיות נבעו מנסיון של הראוטר לתמרן את התקשורת בחלקה לפעמים דרך ה-LTE, ואז החבילות החוזרות משרת הטלפוניה פשוט הלכו לאיבוד. אני צריך לבצע עוד כמה נסיונות כדי לוודא שזה באמת היה זה (ולא עדיפות נמוכה מדי של התקשורת, למרות שכן הגדרתי QoS בדיוק לפי ההמלצות שראיתי).
אם זו אכן הבעיה, מוזר שלא נתקלתי בשום דבר כזה בחיפוש בגוגל, אולי קונפיגורציה כמו אצלי של Load Balance בשילוב עם טלפוניה מיושנת זה לא משהו שרבים מדי עושים.

[sys_admin]

...

...

·

תודה על התגובות, אכן כבר גיגלתי בנוגע לפיצ'ר הזה וראיתי שיש - ובצדק - קונצנזוס לבטל אותו. הבעיות שתיארתי הופיעו אצלי כשהוא כבר מבוטל, אחרת מתקבל 403 Forbidden ורק בנס אפשר להוציא בכלל איזו שיחה.
טיפ למי שרוצה לבצע את זה כמו שצריך: בניגוד למה שרשום שם בקישור, לא מספיק לבטל רק את ה- Checkbox הראשי (Enable ALG), זה לא באמת מבטל, גם לא אחרי REstart לראוטר. מוכרחים לבטל קודם בנפרד את הפיצ'ר עבור כל אחד מהפרוטוקולים SIP ו- RSTP, לבצע restart ורק אז לבטל את Enable ALG.


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

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

SIp Proxy אין לי בראוטר הזה.

בסופו של דבר נראה לי שפתרתי את הבעיה. הלכתי בכיוון שנתת שהבעיה היא ב- NAT, ומצאתי בראוטר אפשרות להגדיר Route Policies. הגדרתי שם לתת עדיפות עליונה לתקשורת ממתאם השיחות אל השרת של המרכזיה וממנו למתאם (האפשרויות הן בין 0 ל- 250 וברירת המחדל היא 150), הגדרתי גם דרך איזה חיבור WAN זה מוכרח להתבצע (כי הנתב מתמרן בעקרון בין חיבור VDSL לסלולרי) - ונכון לעכשיו, אחרי המון נסיונות מוצלחים נראה שהכל עובד ללא שום שגיאות.
אני עדיין לא מבין למה ההגדרות של Qos שחשבתי שאמורות לבצע בדיוק את אותה פעולה של מתן עדיפות והקטנת Latency למינימום , לא עזרו כמעט בכלל.

...

·
רעיון של VPN הוא בזה, שהמתאם יהיה נגיש ישירות למרכזייה ובאותה הרשת הפנימית. ובשביל זה VPN צריך להיות של ספק הטלפונייה ( של בזק בינתאומי במקרה שלך ) ובגלל זה שימוש ב VPN חיצונה לא עוזר לנושא. כמובן שהשימוש ב VPN בין מתאם FXS לבין המרכזיה נותן גם את האפשרות גם של אבטחת מידע והשיחות SIP לא מתבצעות על גבי רשת ציבורית וכדבר שגלוי לכל, אלה בצורה מוצפנת. כל ספק טלפונייה היגיוני מעוניין בזה, כי זה גם נותן לו גישה לממשק ניהול של ATA וגם מונע את הבעיות של NAT. מיותר לציין שבזק בינלאומי או ספקי טלפונייה ישראלים אחרים לא נכללים בקטגורייה זו של ספקים היגיוניים, לפחות לא במה שקשור בהתנהלות מול הלקוחות הביתיים.
בכל מקרה, במצב שהמתאם כרגע נמצא מאחורי NAT של נתב ביתי לא ניתן יהיה לסמוך על זה כעל קו טלפון שמקבל שיחות בצורה עקבית. זה בגלל שיכולות להיות גם בעיות שלקוח SIP פשוט מאבד את הרישום בשרת SIP ובשלב זה השיחות לא יגיעו ליעדן. אופצייה אחרת לפתרון, שבשימוש בכמה עשורים אחרונים בחו''ל בהקשר זה, היא שימוש בפרוטוקול IPv6 , כך פותרים את הבעיה של NAT בין הלקוח SIP לבין המתג ( המרכזייה ). אבל גם פתרון זה לא זמין בדרך כלל ללקוחות ביתיים בישראל בגלל שגם לא מסופקת כישוריות כזו להם, גם לא ניתן טווח כתובתות נדרש לזה וגם המתאמים שמחולקים להם בכלל לא תומכים בצורה תקינה ב IPv6 . בכלל ניתוב ישיר בין לקוח למרכזייה ב SIP נדרש גם לזה שלא יתבצע sip re-invite, שהוא אחד הסיבות לירידת איכות השיחה, לעומס על המרכזייה ולשיחות שלא מגיעות בצורה אקראית ליעדן ברשת זו.
אפשרות נוספת לפתרון היא, אם בזק בינלאומי היו נותנים לך עוד 4 כתובות IPv4 חוקיות כך היית יכול ליצור רשת DMZ פנימית עם כתובת חוקית שניתן לשייח למתאם ובא לציון גואל. זה בקצרה האפשרויות שעמודות לפניך.

[amdr1]

עוד פתרון שיעבוד ב100%
עברה לתשתית הוט ללא חייגן-
עם זו בכלל רלוונטי.
שם מקבלים עד 3 כתובות ipv4 בלי שום בעיה ועלות נוספת.
ומשגם טוב שהקופסה המזדאינת הזות בכזות טופולוגיה נימצת מחוץ לרשת ביתית.

[oferlap]

...

...

·
אם בזק בינלאומי היו נותנים לך עוד 4 כתובות IPv4 חוקיות כך היית יכול ליצור רשת DMZ פנימית עם כתובת חוקית שניתן לשייח למתאם ובא לציון גואל. זה בקצרה האפשרויות שעמודות לפניך.

...

·

כרגע נראה שהכל עובד כמו שמעולם לא עבד - הוצאתי והכנסתי עשרות שיחות ופקסים, בלי שום בעיה. מכאן ואילך זה רק מקצה שיפורים.
לגבי כתובות נוספות מהספק, יש משתמשים ביתיים שקיבלו דבר כזה בתשתית הזו? בכל אופן, כבר עכשיו המתאם נמצא בתוך רשת DMZ פנימית שהיא Subnet של 10.0.10.0/31, אבל הראוטר יכול באופן עקרוני לחייג בעצמו לכל VPN חיצוני, ולשייך את הכתובת החוקית שמגיעה משם למתאם (במקום ה- NAT שהוא מבצע כרגע לרשת הזאת). אפשר להגדיר את זה כך, ואז תהיה למתאם כתובת חוקית ללא NAT, השאלה אם זה כדאי מאיזו בחינה בהינתן שכרגע העסק כבר עובד. הראוטר הזה על פי היצרן הוא מספיק חזק כדי לעמוד בו זמנית בעשרות חיבורי VPN מוצפנים, כך שמהבחינה הזו אין מה לדאוג, מצד שני, השיחה לא יוצאת מוצפנת מהמתאם - אני יכול להאזין לה בקלות עם Wireshark. אני מניח שדרך VPN חיצוני זה יעבור הרבה יותר תחנות בדרך שיכולות להאזין, מאשר כרגע, כשאני מחובר מכתובת של בזק בינלאומי וגם המרכזייה נמצאת באחת הכתובות שלהם.

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

...

·
גם עכשיו אין לה גישה לתת רשתות אחרות בבית.
לגבי תשתית HOT - אם הסיבים לא יגיעו אלי בשנים הקרובות, אז אולי לא תהיה ברירה אלא לסתום את האף ולעבור ל- 500/10 מגה של HOT.

[sys_admin]

@oferlap
·
דבר ראשון, אם כרגע כבר הכל עובד תקין ועקבי מבחינת קבלה והוצאת שיחות ומבחינת שמיעה דו-צדדית תקינה בכל השיחות, אז זה בסדר ולא צריך לשנות יותר כלום. אבל צריך לקחת בחשבון שאם תזהה שיש בעיה שלא רואים אותה בכל שיחה, אלה מופיע לסרוגין, אז תצטרך להתמודד איתה באחת מן הדרכים שציינתי לפני זה.
בקשר לכתובתות נוספות למשתמשים הביתיים, לא מדובר על זה שיש מיהוא מהם שמקבל את השירות זה בחינם, אלה שמדובר על שירות של CIDR /30 של כתובתות חוקיות מנותבות שמשלמים עליהם ואחרי זה ניתן להשתמש בהם הרשת הביתית הפנימית.
בקשר ל DMZ. כל הרעיון של DMZ, הוא בזה שמדובר על תת רשת עם כתובות חוקיות שמחוברת כרשת משנה מאחורי הנתב ולא מתבצע עלייה NAT. על רשת זו מחברים התקנים שלא סובלים את מנגנון NAT. מה שהגדרת כרגע כ DMZ עם כתובות פנימיות, אין לזה שום קשר לתפיסה של DMZ.
בקשר ל VPN, אם מי שיוצר את החיבור VPN זה הנתב, אז זה כבר צריך להיות VPN Site to Site , אחרת אין לזה שום משמעות, כי המתאם שיחות עוד הפעם נמצא מאחורי NAT. בשביל שיעבוד VPN לרשת פנימית של ספק ה SIP, ואם כתבות VPN בודדת נדרש שאת החיבור VPN זה יבצע המתאם שיחות בעצמו. כך זה עובד בכל הספקי SIP בכל העולם וכך משיגים את הרמת האבטחת מידע הנדרשת את הגישה ישירה בין softswitch ללקוח SIP וגם ניתן לבצע provisioning תקני להתקן FXS.
בקשר לשיחה שיוצאת כרגע מהמתאם שלך. בצורה כפי שזה קיים לך כרגע, ללא שהיא עוברת בתוך ערוץ VPN מוצפן עד לרשת של מרכזייה, אז מן הסתם שלא רק אתה מתוך הרשת הפנימית שלך, אלה שכל אחד שנמצע בכל צומת בדרך יכול בקלות גם להאזין, גם להיתערב בה, גם לבצע שינויים בחיוג וגם לעשות דברים נחמדים אחרים. זו בידיוק הסיבה לזה שכך לא מתנהלים בשום מקום בעולם, אלה רק בישראל.

[egol]

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

[MrYair]

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

...

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

תגיד להם שאתה רוצה קו נייח אז יבינו אותך
SIP זה פרוטוקול ולא קו.

[egol]

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

[oferlap]

כעבור 3 שנים........
כבר הבנתי שיכולות להיות בעיות בתקשורת בין המתאם לבין שרת הטלפוניה של הספק - בדרך כלל כתופעת לוואי של NAT ו/או הגדרות Firewall או עדיפויות ניתוב וכו'.
עכשיו אני מנסה להבין, למה בעיות קורות לי *תמיד* מול מספרי טלפון מסויימים, ו*אף פעם* לא עם אחרים?

למשל:
1. כל ניסוי שאני עושה בשליחה או קבלת פקס מול השירות האינטרנטי MyFax.co.il (קידומת 077, ז"א קוים של הוט?) - תמיד מצליח. בגלל זה חשבתי בעבר, שיש לי יכולת פקס תקינה לחלוטין, אם וכאשר אצטרך.
2. כל ניסוי של שליחת פקס מהבית למכשיר בעבודה (כמעט 100% שזה קו בזק) - מצליח. בכיוון ההפוך - תמיד נכשל. שומעים צפצופי משא ומתן להתחברות אבל איכשהו זה לא מצליח.
3. כל חיוג מקו סלולרי של סלקום אל הפקס בבית - הצפצוף הראשון קוטע מייד את האודיו לשני הכיוונים. גם אחרי שהפקס מתנתק, אי אפשר להרים את השפופרת ולנהל שיחה. אם הפקס לא ענה מלכתחילה - אין אף פעם בעיה לנהל שיחות.
4. כל חיוג מקו סלולרי של פלאפון אל הפקס בבית - שומעים תמיד את הצפצופים, ואחרי שהפקס יורד מהקו אפשר תמיד לעבור לנהל שיחה קולית.

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

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

[sys_admin]

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

...

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

[oferlap]

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

...

על T.38. ניסיתי לפני שנים בעזרתם של התמיכה הטכנית לנטרל את זה במתאם לטובת G.711a, אבל זה עבד רק אם התקשרו אלי. כשאני יזמתי שיחות - הקודק תמיד או כמעט תמיד היה G.729 לא משנה מה ההעדפה שהוגדרה במתאם. התומכים הטכניים לא יכלו לעזור לי מעבר לנקודה זו,
וכמובן שאין לי שליטה על אף אחת מההגדרות בעצמי, אפילו לא במתאם, ודאי שלא בשרת הטלפוניה. עד היום לא התעסקתי עם זה כי אני מקבל את השירות ללא תשלום, עד כמות שיחות מסויימת, אבל אם יש אפשרות להתנייד לספק אחר שאצלו תהיה לי אופציה לשחק עם כמה שיותר הגדרות כרצוני עד שהכל יתקתק כמו קו בזק של פעם - יש מצב שאשקול זאת בחיוב.

[sys_admin]

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

[oferlap]

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

...

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

מסקנות שהגעתי אליהן בינתיים:

1. המתאם יוזם Request: Register בכל דקה בערך, כל עוד הוא מחובר לחשמל.
העניין הוא - על כל 16 קריאות כאלה שהשרת עונה לו בחיוב (Status: 200 OK (Register) ברצף, במשך כרבע שעה - מגיעה תמיד אחת בדיוק שנענית בשלילה (מקבלת תגובה Status: 401 Unauthorized).
החוקיות הזו בתזמון המדוייק הזה חוזרים על עצמם במשך שעות ארוכות ללא שינויים - 16 הצלחות, 1 כישלון, 16 הצלחות, 1 כישלון. זה נמשך גם תוך כדי שיחות פעילות - אבל אין שגיאות בהעברת ובקבלת (RTP, RTCP) מאותו שרת.

2. הרבה פעמים, כשהמתאם מבקש להוציא שיחה (Request: Invite), השרת עונה בהתחלה Status: 100 Trying ואז מסרב - Status: 401 Unauthorized. המתאם מאשר את זה עם Request: ACK, ותוך שבריר שניה מבקש שוב להוציא את השיחה, הפעם זה כן מצליח והשרת משיב Status: 183 Session Progress.
אני לא יודע אם זו שגיאה שדורשת תשומת לב, או שזה מה שאפשר לצפות.

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

שיחה מקו סלולרי של סלקום - המתאם עונה כ- Voice בקודק G.711a, והכל סבבה בינתיים.
ברגע שהפקס מתחיל לצפצף, המתאם מבקש לעבור ל- T.38. השרת לא מסכים ומחזיר שגיאה: Status: 488 Not Acceptable Here.
המתאם בתגובה מבקש לעבור לקודק G.711u (ולא G.711a), והשרת לא מסכים ומחזיר Not Acceptable Here. המתאם מתעקש שוב על G.711u וחוזר חלילה במשך כמה פעמים עד שהשרת מפסיק לתת שגיאה. מכאן ואילך נוצר שיח חרשים - השרת משדר G.711a, המתאם משדר G.711u,.ואין סאונד לשני הצדדים. אם מחכים מספיק זמן במצב הזה, תוך משהו כמו דקה השרת מבקש לנתק את השיחה. המתאם מתעלם גם מהבקשה הזו וממשיך להציף חד צדדית ב- G.711u עד שמורידים את השפופרת.

השוואה לסנריו זהה - שיחה מקו סלולרי של גולן טלקום,
הכל קורה כמעט אותו הדבר - G.711a, הפקס מצפצף, המתאם מבקש T.38, גם הפעם השרת לא מסכים, וגם הפעם המתאם מבקש לחזור ל- G.711u במקום ל- G.711a.
ההבדל הוא, שהשרת דווקא כן מסכים על G.711u, והשיחה ממשיכה להתנהל בסבבה מכאן והלאה על G.711u.

השוואה נוספת - שיחה מקו סלולרי של חברת פלאפון. שוב מתחילים ב- G.711a והכל סבבה. הפקס מצפצף - כאן השרת מסכים לבקשת המתאם לעבור ל- T.38. אחרי בערך חצי דקה של נסיונות סנכרון עקרים מצד המתאם, השרת מבקש לחזור ל- G.711a. המתאם מסכים, אבל לא משדר שום תוכן, רק מקבל.
התוצאה היא שמיעה חד צדדית מהסלולרי לכיוון הטלפון הקווי אבל בכיוון ההפוך אין שמע.

השוואה נוספת - שיחה מקו נייח (עסקי) של חברת סלקום
המתאם לא מבקש לעבור ל- T.38 למרות הצפצוף של הפקס. השיחה פשוט נמשכת כ- Voice G.711a ואין שום בעיה.


3. סנריו של שיחה נכנסת במטרה לשלוח אלי פקס:

מקו נייח פרטי של בזק - אין בעיות, הדפים עוברים בקצב 14,400 ללא ECM.
המתאם מבקש לעבור ל- T.38 כ- 4 שניות מתחילת השיחה, השרת מסכים והכל ממשיך בסבבה.

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

מקו נייח עסקי של סלקום - לא עובר.
מתחיל G.711a, השרת (ולא המתאם) מבקש לעבור ל- T.38 כ- 9 שניות מתחילת השיחה. המתאם מסכים, אבל לא משדר כלום, צרצרים. השרת משדר חד צדדית T.38 מבלי לקבל שום כלום מהמתאם, ואחרי בערך חצי דקה כזו, המתאם (ולא השרת) מודיע שניתק את השיחה.


4. סנריו של שיחה יוצאת במטרה לשלוח פקס:

אל קו נייח של בזק - עובר בלי בעיות.
שיחה מתחילה ב- G.711a, מתאם מבקש T.38 כ- 3 שניות מתחילת שיחה, שרת מסכים, פקס מסתנכרן על 14,400 והכל סבבה.

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

אל קו נייח עסקי של סלקום - עובר.
שיחה מתחילה ב- G.729 (ולא G.711a).
מתאם מבקש T.38 כ- 6 שניות מתחילת השיחה, השרת מסכים, מסתנכרנים על 14,400 ללא ECM והכל סבבה.


5. שיחות קוליות יוצאות:

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

[sys_admin]

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

[oferlap]

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

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