גימגום השיחה בטלפון

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

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

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

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

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

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

3 מחשבות על “גימגום השיחה בטלפון

  1. צפריר כהן

    שתי הערות:

    1. מה שנעשה ב־jitter buffer אינו קיבוץ של מספר חבילות נכנסות לחבילה יוצאת אחת אלא שחרור החבילות היוצאות בקצב אחיד.

    2. הנה דוגמה לאיכות החיבור:
    $ ping -c 10 yahoo.com
    PING yahoo.com (98.139.183.24) 56(84) bytes of data.
    64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_req=1 ttl=48 time=577 ms
    64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_req=2 ttl=49 time=533 ms
    64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_req=3 ttl=48 time=594 ms
    64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_req=4 ttl=48 time=668 ms
    64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_req=5 ttl=49 time=629 ms
    64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_req=6 ttl=48 time=591 ms
    64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_req=7 ttl=48 time=719 ms
    64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_req=8 ttl=49 time=743 ms
    64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_req=9 ttl=48 time=871 ms
    64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_req=10 ttl=49 time=803 ms

    — yahoo.com ping statistics —
    10 packets transmitted, 10 received, 0% packet loss, time 8998ms
    rtt min/avg/max/mdev = 533.342/673.269/871.046/103.329 ms

    (יש לציין שבמקרים רבים חבילות ICMP מקבלות טיפול ותעדוף שונה מחבילות TCP או UDP שונות ולכן המספרים שתקבלו מפינג לא ישקפו את מה שחבילות ה־VoIP יעברו. אבל מה שרואים כאן מספיק טוב).

    פקודת ping שולחת חבילה קטנה ומבקשת מהצד השני לשלוח תגובה. היא מציינת כמה זמן זה לקח (הלוך + חזור + זמן עיבוד במערכת היעד. בד"כ זניח).

    במקרה שלנו הזמן נע בין ~550ms לזמנים גבוהים בהרבה (עד 871ms). גם אם כל התעבורה הייתה עם עיכוב של "550ms" (כלומר: בערך חצי מזה לכל כיוון – קצת פחות מ־300ms), זה כבר היה עיכוב מורגש במקצת (עיכוב של מעל 200ms כבר יכול להיות מורגש).

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

    1. ik_5 מאת

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

      כל מה שאתה כותב נכון (אם כי גם פינג אפשר לכוון לתמוך בudp למשל ולא ב icmp), אבל כל זה רמות נמוכות יותר ממה שרציתי להיכנס אליהם.

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

  2. פינגבק: סיפ, מדוע זה לא פשוט כמו HTTP ? | לראות שונה

כתיבת תגובה

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

הלוגו של WordPress.com

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

תמונת Twitter

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

תמונת Facebook

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

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

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

מתחבר ל-%s