אופטימיזציה של הרשת ל-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 תלויה בקיבולת, בעיכוב, בג'יטר וברמות של אובדן מנות נתונים (packet-loss) שקשה מאוד להשיג בתדר ‎2.4 GHz.

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

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

• ניהול גודל התא, שנשלט על ידי עוצמת השידור של נקודת הגישה (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 להעברת נתונים

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