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

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

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

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

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

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

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

  • source nat המוכרת כ SNAT
  • ו destination nat המוכרת כ DNAT

וכמובן שאפשר להגיע למצב בו שני הרשתות הן מאחורי NAT, ואז יש לנו גם SNAT וגם DNAT ביחד.

כאשר יש רק מערכת בודדת מאחורי ה NAT, אפשר לקבוע סוג של port forwarding, או להעביר כל מידע המגיע מכתובת מסויימת אל מחשב מסויים בתוך הרשת, אך כאשר יש יותר ממערכת אחת, שצריכה תקשורת מאחורי NAT – יש בעיה, וצריך כלים חדשים, כדוגמת STUN, ICE וגם תת פרוטוקול של ICE הנקרא TURN.

עכשיו יש עוד בעיה לטפל בה – כתובת פנימית מול כתובת חיצונית. היות ו NAT בעצם אומר כי נוצרת לנו רשת פנימית (לפחות אחת) בכתובות IP אשר אינן מוכרות בעולם, כדוגמת 192.168, 10 וכיוב', אנחנו צריכים לבצע מספר פעולות ביחד:

  • להגיד מה הכתובת הפנימית לחזור אליה
  • להגיד מה הכתובת החיצונית של המערכת
  • לדעת לנתב פעולות לפי הכתוב

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

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

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

עוד צרה שיש, קיימת בכך שSIP רק מספק לנו תעוד על מה שקורה בדרך כפי שהזכרתי מקודם, כלומר SIP יוצר אותות המספרות לנו את מהלך הדרך, אבל ישנם עוד פרוטוקולים שנכנסים לתוקף. על ה SIP רוכב לו פרוטוקול בשם SDP שהוא בעצם סוג של body (זהה לHTTP ו SMTP), אשר מתאר את המדיה, כאשר זו מסוגלת גם להיות מוצפנת, ולתמוך במספר קודקים שונים, ואפילו להעביר מסרים ומידע שונה.

אבל יש גם עוד פרוטוקולים, כדוגמת RTP שמוכר יותר (וגם אותו הזכרתי מקודם), והוא בעצם המידע הקולי/וויזואלי של שיחה, ויש גם פרוטוקול אחר, שנקרא RTCP אשר התפקיד שלו הוא לשלוט ב RTP עצמו. השליטה היא ההבנה בעצם של המידע, כדוגמת מהירות דגימה, בעיות משלוח, בעיות שעון (תזמון), בעיות תעבורה, שליטה ב jitter, ביצוע QoS ועוד.

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

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

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

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

  1. פינגבק: webrtc ORTC | לראות שונה

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s