אופטימיזציה של הרשת ל-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.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, כך שתוכלו לזהות את תנועה של נתוני מדיה קולית שמשמשת ב-Google Workspace ולתת עדיפות נמוכה יותר לתנועה של נתוני מדיה קולית מחשבונות פרטיים. כך תוכלו להגדיר ולבצע אופטימיזציה של הגישה לרשת ולחומת האש בצורה טובה יותר.

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

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

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

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