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

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

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

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

• בהגדרת שרת ה-proxy, מוסיפים את התנועה ב-Voice לרשימת ההיתרים.
• ב-Voice אין מעבר חזרה ל-TCP כמו ב-Google Meet. ‫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 תלויה בקיבולת, בעיכוב, בג'יטר ובשיעור אובדן המנות (packet-loss) ברמה מספקת, וקשה מאוד להשיג את הרמה הזו ברוחב פס של 2.4GHz.

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

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

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

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

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

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

בשלב האחרון, מומלץ לערוך סקר אחרי הפריסה האלחוטית כדי לוודא שיש כיסוי אלחוטי בכל המרחבים שבהם משתמשים בדרך כלל ב-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 למשתמשים או לדפדפנים.