אופטימיזציה של הרשת ל-Voice

תשתית רשת שמתאימה לענן מאפשרת לתעבורת הנתונים של Voice לתקשר ביעילות עם התשתית של Google. כדי ליצור את זה:

• לוודא שלתנועה ב-Voice יש נתיב קצר לאינטרנט. מה לא:
  • שרתי Proxy
  • בדיקת חבילות או מנתחי פרוטוקולים
• מדידה ואופטימיזציה:
  • זמן אחזור: עיכוב של עד 150 אלפיות השנייה בכיוון אחד (ITU G114)
  • רוחב פס: מומלץ 50Kbps
  • רשת Wi-Fi: אפשר לעיין בשיטות מומלצות לשימוש ב-Wi-Fi

מומלץ מאוד לא להשתמש בשרתי proxy לתנועה ב-Voice:

• בהגדרות של שרת ה-proxy, מוסיפים את התנועה של Voice לרשימת ההיתרים.
• בניגוד ל-Google Meet, ב-Voice אין חזרה ל-TCP. ‫Voice משתמש ב-UDP רק לתנועת קול.
• שימוש בשרת proxy לתנועה מאריך את זמן האחזור, ועלול לגרום למערכת Voice להפחית אוטומטית את איכות האודיו. הביצועים ב-Voice הכי טובים כשזמן האחזור בין הלקוח לבין הקצה העורפי של Google הוא פחות מ-100 אלפיות השנייה.
• פרוטוקול האינטרנט Socket Secure‏ (SOCKS5) לא נתמך.

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

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

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

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

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

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

תדרי רדיו של ‎2.4 GHz לעומת ‎5 GHz

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

תדר הרדיו של ‎2.4 GHz בעייתי כי יש בו רק 3 ערוצים לא חופפים, ולרוב יש בו רמות רעש גבוהות מרשתות בקרבת מקום שמפריעות, והפרעות נוספות ממכשירים אחרים (למשל, מיקרוגלים), שיוצרים סביבת RF רועשת ומורכבת.

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

שיקולים לגבי התכנון והפריסה

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

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

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

• ההמלצה היא לא לחבר יותר מ-10 טלפונים שולחניים לאותה נקודת גישה. מספר גדול יותר עלול ליצור חוויית משתמש בלתי צפויה.
• צוותים שמשתמשים בטלפון בתדירות גבוהה, כמו נציגי מכירות או צוותי תמיכה, לא צריכים להשתמש בטלפונים שולחניים שמחוברים באופן אלחוטי. לדוגמה, אתרי GOVO או מוקדים טלפוניים שפועלים מסביב לשעון.
• בטלפונים שולחניים שמחוברים לרשת אלחוטית, צפויות הפרעות קצרות בקול (פחות מ-10 שניות) ואי אפשר למנוע אותן ברמת הרשת. אנחנו לא ממליצים להשתמש ברשתות אלחוטיות לשיחות טלפון חשובות, כמו ועידות, מסיבות עיתונאים או שיחות של מנהלים.
• למרות שהתקנות משתנות בין מדינות או אזורים, דרישה נפוצה היא שמכשירי Wi-Fi שמשתמשים בערוצי DFS יוודאו שהם לא יפריעו למערכת מכ"ם מזג האוויר המקומית, למשל. כתוצאה מכך, נקודת גישה שחשופה להפרעות של מכ"ם תפנה את הערוץ. כל הלקוחות יצטרכו להתחבר מחדש לנקודת גישה אחרת שפועלת בערוץ אחר.

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

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

תנועת הנתונים של Voice מאובטחת ומוצפנת, כך שאין צורך להגביל את התנועה לכתובות ה-IP של Google.

עם זאת, אם יש לכם אילוצי רשת שמחייבים אתכם להגביל את התנועה, הוסיפו את טווחי כתובות ה-IP הבאים לרשימת ההיתרים כדי לאפשר את שרתי המדיה של Voice. כתובות ה-IP משמשות באופן בלעדי את Voice for Google Workspace, כדי שתוכלו לזהות את תנועת הנתונים של Voice שמשמשת ב-Google Workspace ולהוריד את העדיפות של תנועת הנתונים של Voice מחשבונות צרכנים. כך תוכלו להגדיר ולבצע אופטימיזציה של הגישה לרשת ולחומת האש בצורה טובה יותר.

• IPv4: ‏ 74.125.39.0/24
• IPv6: ‏ ‎2001:4860:4864:2::0/64

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

• יציאות UDP יוצאות 19302 עד 19309
• יציאת TCP‏ 443 להעברת נתונים

הערה: טווח היציאות של Voice‏ 19302 עד 19309 משתמש בהגדרת יציאות ה-UDP של Chrome WebRTC. מידע נוסף זמין במאמר הגדרת מדיניות Chrome למשתמשים או דפדפנים.