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

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

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

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

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

אם אפשר, אל תשתמשו בבדיקת חבילות או במנתחי פרוטוקולים ל-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 שעות ביממה, 7 ימים בשבוע.
• הפרעות קצרות בדיבור, שנמשכות פחות מ-10 שניות, הן צפויות ואי אפשר למנוע אותן ברמת הרשת בטלפוני IP שמחוברים באופן אלחוטי. לא מומלץ להשתמש ברשתות אלחוטיות לביצוע שיחות טלפון חשובות, כמו שיחות ועידה, פגישות עם עיתונאים או שיחות עם מנהלים.
• התקנות משתנות ממדינה למדינה ומאזור לאזור, אבל דרישה נפוצה היא שמכשירי Wi-Fi שמשתמשים בערוצי DFS לא יפריעו למערכת מכ'ם מזג האוויר המקומית, למשל. כתוצאה מכך, נקודת גישה שנתונה להפרעות של מכ"ם תפנה את הערוץ. כל הלקוחות יצטרכו להתחבר מחדש לנקודת גישה אחרת שפועלת בערוץ אחר.

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

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

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

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

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

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

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

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