המאמר הזה מיועד לאדמינים. במרכז העזרה של Meet אפשר לקרוא איך להגדיר ולנהל את הפגישות האישיות שלכם.
המאמר הזה מיועד לאדמינים ב-IT שמנהלים את Meet בארגונים גדולים, עם מאות ואלפי עובדים וצרכים מורכבים בנוגע לשימוש ברשת. אם אתם לא עונים על הקטגוריה הזו, אין צורך לקרוא את המאמר הזה שמתייחס להיבטים טכניים רבים.
אם אתם אדמינים ב-IT שרוצים לפתור בעיות ברשת בנוגע ל-Meet, כדאי לקרוא את המאמר בנושא פתרון בעיות ברשת, באודיו ובווידאו ב-Meet לאדמינים.
אם אתם מנסים להשבית את Meet עבור כל הארגון, כדאי לקרוא את המאמר שמסביר איך משביתים בארגון את הפגישות והשיחות ב-Meet.
כדי לקיים פגישות באיכות גבוהה באמצעות Google Meet, עליכם להגדיר את הרשת כך שמערכת Meet תוכל לתקשר ביעילות עם התשתית של Google. אתם צריכים:
- לוודא שלתנועה ב-Meet יש נתיב קצר לאינטרנט.
- להימנע משימוש בשרתי proxy, מבדיקת חבילות, ממנתחי פרוטוקולים ומשימוש ב'איכות השירות (QoS)'.
- למדוד את זמן האחזור, רוחב הפס ורשת ה-Wi-Fi, ולבצע אופטימיזציה שלהם.
איך מגדירים את הרשת
שלב 1: הגדרה של יציאות להעברת נתונים לתנועת מדיה- לאודיו ולווידאו, מגדירים את יציאות ה-UDP להעברת נתונים: 3478 וגם 19302-19309.
- כדי להגביל את מספר יציאות ה-WebRTC של Chrome שבשימוש, צריך להשתמש ביציאות שמפורטות ביציאות WebRTC UDP.
- אפשר גם להגביל את היציאות האלה באמצעות חומת האש.
- לתנועה באינטרנט ולאימות משתמשים, צריך להשתמש ביציאת ה-UDP להעברת נתונים וביציאת ה-TCP 443.
היציאות מותרות ללא הגבלה של IP. אם יציאות ה-UDP חסומות, ייעשה שימוש ב-TCP. שימוש ב-TCP או ב-TCP דרך שרת proxy עלול לפגוע באיכות הכוללת של הפגישה.
צריך לתת ל-Meet גישה מלאה לרשת.
- אם יש הגבלות או מדיניות סינון למשתמשים ברשת, עליכם להעניק לרשת גישה לרשת לתבניות ה-URI שמפורטות בהמשך הדף הזה באמצעות יציאה 443.
- אם אתם משתמשים בציוד ל-Google Meet, יש לעיין בדרישות הרשת ל-ChromeOS במאמר בנושא הגדרה של בדיקת TLS (או SSL) במכשירי Chrome.
דומיינים למשאבים סטטיים
- clients2.google.com
- clients4.google.com
- clients6.google.com
- www.gstatic.com
- fonts.gstatic.com
- lh3.googleusercontent.com
- meetings.clients6.google.com
דומיינים לקישוריות של נקודות קצה ל-API
- accounts.google.com
- apis.google.com
- meetings.googleapis.com
- hangouts.googleapis.com
- meet.google.com
- apps.google.com
- jamboard.google.com
- docs.google.com
דומיינים לסטרימינג בשידור חי
- stream.meet.google.com
- youtube.googleapis.com
- www.youtube-nocookie.com
- googlevideo.com
דומיינים למשוב ממשתמשים והעלאות של יומני אירועים
- https://www.google.com/tools/feedback
- https://feedback.googleusercontent.com/resources/
- https://play.google.com/log
- אם הארגון שלכם צריך לתמוך בתנועה ב-Meet ביציאה 443, מוסיפים את Meet SNI לחומת האש או לרשימת ההיתרים של שרת ה-proxy כדי לאפשר תנועה של אודיו ווידאו ב-TLS. כתובות ה-IP האלה שונות ממזהי ה-URI שצוינו בשלב 2.
- מוסיפים את טווחי כתובות ה-IP של Google Workspace (למשתמשים שלכם). נותנים גישה לשרתי המדיה של Meet באמצעות טווחי ה-IP וה-SNI הבאים:
- IPv4: 74.125.250.0/24
- IPv6: 2001:4860:4864:5::0/64
- SNI: workspace.turns.goog
- אם בארגון משתמשים בסטרימינג בשידור חי עם זמן אחזור נמוך, תהיה עדיפות לשימוש בפרוטוקול UDP לתנועת המדיה של .הסטרימינג בשידור חי. המערכת תשתמש עבור התנועה בטווחי כתובות ה-IP של Workspace, בדומה ל-Meet, במקום בכתובות ה-IP בפרוטוקול HTTP של YouTube.
- מוסיפים את טווח כתובות ה-IP של צרכנים. נותנים גישה לשרתי המדיה של Meet באמצעות טווחי ה-IP הבאים:
- IPv4: 142.250.82.0/24
- IPv6: 2001:4860:4864:6::/64
- SNI: meet.turns.goog
ברשת שלכם צריך להיות רוחב פס שמאפשר לקיים בו-זמנית כמה פגישות וידאו באיכות HD. צריך גם להיות רוחב פס נוסף לצרכים אחרים, כמו סטרימינג בשידור חי. יש גורמים נוספים שמשפיעים על השימוש ברוחב הפס, כמו מספר המשתתפים, שיתוף המסך ועוד.
אם אין ברשת מספיק רוחב פס, מערכת Meet תוריד את איכות הווידאו. אם אין ברשת מספיק רוחב פס לתמיכה בווידאו, צריך להגדיר את Meet לשימוש באודיו בלבד.
חישוב הדרישות המינימליות של רוחב הפס ב-Meet
כדי לחשב את דרישת רוחב הפס המינימלית לארגון שלכם, מכפילים את רוחב הפס הממוצע לכל אחד מהנוכחים במספר השיא של הנוכחים בו-זמנית.
גורמים רבים, כמו מספר המשתתפים, אפשרויות הפריסה ושיתוף המסך, יכולים להשפיע על השימוש ברוחב הפס. אם שיתוף המסך קבוע, הוא לא דורש יותר רוחב פס לאחר שהוא נטען.
| רוחב פס ממוצע לכל נוכח בארגונים גדולים | ||
|---|---|---|
| סוג הפגישה | להעברת נתונים | לקבלת נתונים |
| וידאו | 1 Mbps | 1.3 Mbps |
| אודיו בלבד | 12 Kbps | 18 Kbps |
| רוחב פס לכל נוכח בארגונים קטנים או בשיחות בין אנשים | ||
|---|---|---|
| סוג הפגישה | להעברת נתונים | לקבלת נתונים |
| וידאו ברזולוציה 1080p | עד 3.6 Mbps | עד 3.6 Mbps |
| וידאו ברזולוציה 720p | עד 1.7 Mbps | עד 1.7 Mbps |
| פגישה קבוצתית | 250 Kbps ומעלה* | עד 4.0 Mbps |
| אודיו בלבד | 100 Kbps | 100 Kbps |
*בהתאם לרזולוציה שנשלחת
איך מעריכים את מספר השיא של הנוכחים בו-זמנית
אם הפגישות ב-Meet הן בעדיפות גבוהה, אפשר להעריך ש-20% מהמשתמשים בארגון שלכם ישתמשו ב-Meet בו-זמנית בנקודת זמן כלשהי. אם הפגישות ב-Meet הן בעדיפות נמוכה, רק 0.5% מהאנשים עשויים להשתתף בפגישה ב-Meet בו-זמנית.
| עדיפות לפגישות וידאו | אחוז משוער של נוכחים בפגישות בו-זמנית |
|---|---|
| גבוהה | 10-20% |
| רגילה | 1-4% |
| נמוכה | 0.01-0.5% |
דרישות רוחב הפס לכל פיד של שידור חי
אם בארגון שלכם מבצעים סטרימינג של פגישות בשידור חי, רוחב הפס האידאלי לכל פיד צפייה הוא 2.6 Mbps. שידורים חיים כוללים אפשרויות דינמיות של פריסה ושינוי גודל. המערכת מבצעת אופטימיזציה לפי יכולות המכשיר, כמו גודל החלון ויחס גובה-רוחב. אם לנוכח מסוים יש מספיק רוחב פס, מערכת Meet משתמשת בהגדרת ברירת המחדל של וידאו באיכות גבוהה.
אם אין לצופים מספיק רוחב פס, הם יכולים להפחית את האיכות ב-Meet או להשתמש באודיו בלבד.
פיד וידאו יחיד (קצב העברת נתונים ב-Kbps)
|
רזולוציה |
מינימום |
מקסימום |
|
180p |
80 |
200 |
|
360p |
200 |
500 |
|
540p |
400 |
1000 |
|
720p |
600 |
1500 |
פיד שיתוף המסך (קצב העברת נתונים ב-Kbps)
|
רזולוציה |
מינימום |
מקסימום |
|
איכות מינימלית |
200 |
200 |
|
360p |
250 |
500 |
|
720p |
750 |
1500 |
|
1800p |
1300 |
2600 |
רוחב הפס לגרסה הקלאסית של סטרימינג בשידור חי (זמן אחזור לא מאוד נמוך)
כדי לבדוק באיזו גרסה של סטרימינג בשידור חי נעשה שימוש בדומיין, בודקים מה מוצג אצל הלקוח. ללקוח של הגרסה הקלאסית של סטרימינג בשידור חי מופיע סרגל לבן בחלק העליון עם אמצעי בקרה. ללקוח של הגרסה החדשה של סטרימינג בשידור חי יש עיצוב כהה כמו ב-Meet וכל אמצעי הבקרה מוצגים בחלק התחתון.
| רזולוציה | מינימום | מקסימום |
|---|---|---|
| 360p | 400 Kbps | 1 Mbps |
| 720p | 1.5 Mbps | 4 Mbps |
| 1080p | 3 Mbps | 6 Mbps |
רוחב הפס בפועל משתנה בהתאם לסוג התוכן שמועבר בשידור החי.
שיטות מומלצות לשימוש ברשת
כדי לצמצם את השימוש ברוחב הפס, כדאי להגדיר את ברירת המחדל לאיכות הווידאו ב-Meet במסוף Google Admin.
ההגדרה הזו רלוונטית רק לדפדפני אינטרנט, ולא משפיעה על הציוד ל-Google Meet או על אפליקציות Meet לנייד.
כדי לבטל את ערך ברירת המחדל של היחידה הארגונית בדפדפן, המשתמשים יכולים להפעיל וידאו בפגישה ב-Meet ולשנות את איכות הווידאו. הגדרת ברירת המחדל תחול על כל פגישה חדשה שהמשתמש יצטרף אליה.
-
-
במסוף Admin, נכנסים לתפריט
אפליקציות
Google Workspace
- לוחצים על הגדרות הווידאו ב-Meet.
- בצד ימין, בוחרים את היחידה הארגונית שרוצים לנהל. לכל המשתמשים, בוחרים את היחידה הארגונית שברמה העליונה.
- בוחרים אפשרות לאיכות הווידאו:
- התאמה אוטומטית (ברירת מחדל) – רוחב הפס מותאם לתנאי הרשת והמערכת כדי לספק את האיכות הטובה ביותר האפשרית.
- רוחב פס מוגבל לווידאו – רוחב הפס להעברת וידאו מוגבל ל-1 Mbps.
- אודיו בלבד – הווידאו כבוי כברירת מחדל. המשתמשים יכולים ללחוץ על
כדי להפעיל את המצלמה שלהם בחלון הדפדפן של Meet. המהירות להעברת הווידאו תוגבל ל-1 Mbps.
- מחילים את ההגדרות:
- אם ההגדרה היא ליחידה הארגונית ברמה העליונה, לוחצים על שמירה.
- אם ההגדרה היא ליחידת צאצא ארגונית והיא שונה מזו של ההורה, לוחצים על שינוי.
ההמלצות הבאות רלוונטיות לסביבות משרדיות אופייניות. מהנדס של תוכנה אלחוטית צריך לבצע הערכה לגבי סביבות מורכבות יותר כמו:
- רצפות ייצור
- אזורים עם רמות גבוהות של רעש תדרי רדיו
- אזורים שבהם הכיסוי האלחוטי נמוך
חשוב לקרוא בעיון את השיקולים הבאים בזמן התכנון, הפריסה וההפעלה של הרשתות האלחוטיות שמיועדות לשמש את Meet.
תדרי רדיו של 2.4 GHz לעומת 5 GHz
אנחנו ממליצים שהרשת תאלץ את הלקוחות לעבור לתדר רדיו של 5 GHz, אם הוא זמין.
מומלץ לא לפרוס ולא להפעיל את Meet באמצעות תדר רדיו של 2.4 GHz של רשת אלחוטית, כי בדרך כלל התדר הזה עמוס מאוד. בנוסף, תדר הרדיו של 2.4 GHz פחות מהימן כי יש בו 3 ערוצים לא חופפים, רמות רעש גבוהות והפרעות נוספות.
שיקולים לגבי התכנון והפריסה
לרשת האלחוטית, כדאי להביא בחשבון את הקיבולת ולא את הכיסוי.
- ניהול גודל התא – צריך לשלוט בגודל התא באמצעות עוצמת השידור של נקודת הגישה (AP). כדי להגדיל את הקיבולת, כדאי לפרוס תאים קטנים יותר במקומות שבהם צפויים להיות יותר מכשירים, כמו חדרי ישיבות ואולמות אודיטוריום. השתמשו בתאים גדולים יותר כדי לספק כיסוי כללי בקומת המשרד.
- השביתו שימוש בשיעורי תעבורה נמוכים כדי לשפר את יעילות השימוש בתדרי רדיו – וכדי לאלץ את הלקוח לעבור ל-AP הקרוב ביותר בזמן נדידה בין נקודות AP.
- נהלו את הרשת באופן ריכוזי — כדי לאפשר שימוש בתכונות מתקדמות כמו נדידה חלקה בין נקודות גישה וניהול תקין של תדרי רדיו, צריך לנהל ולהפעיל רשת אלחוטית באופן ריכוזי. לא כדאי לנהל את הרשת כאוסף של נקודות גישה עצמאיות.
- בדקו את הרשת האלחוטית אחרי הפריסה – חשוב לוודא שיש כיסוי אלחוטי במרחבים שבהם משתמשים בדרך כלל ב-Meet.
שימוש ב-WMM
כדי לתמוך בתקשורת מהימנה ב-Meet באמצעות רשתות אלחוטיות, עליכם להטמיע תוספי מולטימדיה אלחוטיים (WMM).
צריך לסווג את התנועה ב-Meet באחת מהדרכים הבאות:
- הבקר האלחוטי או ה-AP על סמך הפרוטוקולים והיציאות הספציפיים ל-Meet.
- ערך השדה 'מיקום התו (code point) לשירותים מבודלים' (DSCP) שהוגדר על ידי ציוד רשת אחר. אם הרשת מספיק מהימנה לדעתכם, השתמשו ב-DSCP.
כדי לספק איכות שירות (QoS) דו-כיווני נדרשת תמיכה מלאה ב-WMM. למרות זאת, אפשר להגדיר זאת ברמת הרשת ועדיין לקבל יתרונות משמעותיים. התנועה ב-Meet צריכה להיות מוקצית לתור האודיו או הווידאו בבקר או ב-AP האלחוטי. התנועה ב-Meet צריכה לקבל עדיפות על פני סוגי תנועה אחרים.
סביבות VDI יוצרות שכבה נוספת בין Meet והאינטרנט. הן עשויות להאט את Meet וליצור חוויית שימוש באיכות נמוכה יותר. השימוש באפקטים ברקע מוגבל, והתצוגה המקדימה של חדר ההמתנה לא זמינה.
כדי להפחית את ההשפעה שיש לשימוש ב-VDI על Meet, אפשר לבצע את הפעולות הבאות:
- ודאו שמערכת Google Meet יכולה לזהות שהיא פועלת במכונה וירטואלית (VM), על ידי הפעלה של המדיניות Enterprise Hardware Platform API ב-Chrome. פרטים נוספים זמינים במאמר הגדרת מדיניות Chrome למשתמשים או דפדפנים ובדף ה-API.
- צריך להקצות לפחות 4 מעבדים (CPU) וירטואליים לכל מכונה וירטואלית.
- אין צורך ב-GPU עבור אפקטים ברקע, אבל מכונות VM שתומכות ב-GPU מגבירות את המהימנות שלהם.
- ודאו שיש מספיק רוחב פס וזמן אחזור קצר בין לקוחות שונים, מחשבים וירטואליים ושרתי מדיה של Meet. למידע על דרישות רוחב הפס בין שרתי המדיה של Meet לבין מכונות VM, עיינו בשלב 4 (למעלה בדף הזה). גלו מה רוחב הפס הדרוש לחיבור בין לקוחות VDI למכונות וירטואליות, על ידי בירור עם ספק ה-VDI שלכם.
השיטה המומלצת ביותר היא לא להשתמש בשרתי proxy לתנועה ב-Meet. שימוש בשרת proxy לתנועה מאריך את זמן האחזור, ולכן עלול להפחית את איכות הווידאו.
אם צריך להשתמש בשרתי proxy ברשת
אם אתם צריכים להשתמש בשרת proxy, חשוב להבין ששרתי proxy יכולים להשפיע בצורה משמעותית על הביצועים ולוודא:
- שיש גישה לתנועה ב-Meet בהגדרה של שרת ה-proxy.
- שמערכת Meet משתמשת בהגדרות Chrome לשרת ה-proxy.
- שהרשת עוקפת את שרת ה-proxy לכתובת ה-IP וה-SNI של Meet.
פרוטוקול האינטרנט Socket Secure (SOCKS5) לא נתמך בשלב הזה.
- אם יש לכם סיבה טובה לכך, למשל רשת עמוסה
- אם אתם יכולים לפרוס ולתחזק מודל QoS מקצה לקצה ברשת.
אם חייבים להשתמש ב-QoS
השיטה המומלצת ביותר היא לא להשתמש ב-VPN לתנועה ב-Meet. שימוש ברשתות VPN מאריך את זמן האחזור, ועלול לגרום למערכת Meet להפחית את איכות הווידאו והאודיו.
אם אתם חייבים להשתמש ב-VPN:
- הפעילו מנהור מפוצל ל-VPN.
- נתבו את הדומיינים משלב 2 אל מחוץ ל-VPN באמצעות ה-DNS או ה-SNI (מומלץ להשתמש ב-SNI).
- נתבו את הטווחים של כתובות ה-IP משלב 3 מחוץ ל-VPN באמצעות התאמת קידומת.
נושאים קשורים
Google, Google Workspace והסימנים וסמלי הלוגו הקשורים אליהם הם סימנים מסחריים של Google LLC. כל שמות החברות והמוצרים האחרים הם סימנים מסחריים של החברות שאליהן הם משויכים.
