המאמר הזה מיועד לאדמינים. במרכז העזרה של 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, גם דרך שרת proxy, עלול לפגוע באיכות הכוללת של הפגישה.
שלב 2: מתן גישה למזהי משאבים אחידים (URI)
צריך לתת ל-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
- docs.google.com
דומיינים לסטרימינג בשידור חי
- meet.google.com
- stream.meet.google.com
דומיינים למשוב ממשתמשים והעלאות של יומני אירועים
- https://www.google.com/tools/feedback
- https://feedback.googleusercontent.com/resources/
- https://play.google.com/log
שלב 3: מתן גישה לטווחים של כתובות ה-IP של Google (לאודיו ולווידאו)
- אם הארגון שלכם צריך לתמוך בתנועה ב-Meet ביציאה 443, תוסיפו את Meet SNI לחומת האש או לרשימת ההיתרים של שרת ה-proxy כדי לאפשר תנועה של אודיו ווידאו ב-TLS. כתובות ה-IP האלה שונות ממזהי ה-URI שצוינו בשלב 2.
- מוסיפים את טווחי כתובות ה-IP של Google Workspace (למשתמשים בארגון). נותנים גישה לשרתי המדיה של Meet באמצעות טווחי ה-IP וה-SNI הבאים:
- IPv4: 74.125.250.0/24, 74.125.247.128/32
- IPv6: 2001:4860:4864:5::0/64, 2001:4860:4864:4:8000::/128
- 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
שלב 4: בדיקת הדרישות של רוחב הפס
ברשת שלכם צריך להיות רוחב פס שמאפשר לקיים בו-זמנית כמה פגישות וידאו באיכות HD. צריך גם להיות רוחב פס נוסף לצרכים אחרים, כמו סטרימינג בשידור חי. גורמים שונים משפיעים על השימוש ברוחב הפס, כמו מספר המשתתפים, שיתוף מסך ועוד.
אם אין ברשת מספיק רוחב פס, מערכת Meet תוריד את איכות הווידאו. אם אין ברשת מספיק רוחב פס לתמיכה בווידאו, צריך להגדיר את Meet לשימוש באודיו בלבד.
כדי ליצור שידור חי באמצעות רוחב פס צר יותר, אפשר לארח שידורים חיים מרובי-משתתפים עם רוחב פס צר יותר באמצעות eCDN.
חישוב הדרישות המינימליות של רוחב הפס ב-Meet
כדי לחשב את רוחב הפס המינימלי שנדרש לארגון, מכפילים את רוחב הפס הממוצע לכל אחד מהמשתתפים במספר השיא של המשתתפים שנוכחים בו-זמנית.
גורמים רבים, כמו מספר המשתתפים, אפשרויות הפריסה ושיתוף המסך, יכולים להשפיע על השימוש ברוחב הפס. אם המסך שמשותף הוא סטטי, הוא לא ידרוש יותר רוחב פס אחרי שהוא ייטען.
| רוחב פס ממוצע לכל משתתף בארגונים גדולים | ||
|---|---|---|
| סוג הפגישה | יוצאת | נכנסות |
| וידאו | 1Mbps | 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 |
1,300 |
2,600 |
איכות המדיה בשידור חי מושפעת מהאיכות המקורית של המדיה ומאופן השליחה שלה ל-Meet. אתם יכולים להצטרף לשיחה ב-Meet בתור משתתפים רגילים כדי לבדוק ולהשוות את איכות המדיה בשידור החי.
שיטות מומלצות לשימוש ברשת
איך להגדיר ברירת מחדל לאיכות הווידאו
כדי לצמצם את השימוש ברוחב הפס, כדאי להגדיר את ברירת המחדל לאיכות הווידאו ב-Meet במסוף Google Admin.
ההגדרה הזו רלוונטית רק לדפדפני אינטרנט. ההגדרה הזו לא משפיעה על הציוד ל-Google Meet או על אפליקציות Meet לנייד.
המשתמשים יכולים לבטל את ערך ברירת המחדל של היחידה הארגונית בדפדפן שלהם על ידי הפעלת וידאו בפגישה ב-Meet ושינוי של איכות הווידאו. הגדרת ברירת המחדל תחול על כל פגישה חדשה שהמשתמש יצטרף אליה.
-
במסוף Google Admin, נכנסים לתפריט
אפליקציות Google Workspace Google Meet.כדי לעשות את זה צריך הרשאות אדמין להגדרות השירות.
- לוחצים על הגדרות הווידאו ב-Meet.
- בצד ימין, בוחרים את היחידה הארגונית שרוצים לנהל. אם רוצים להגדיר לכל המשתמשים, בוחרים את היחידה הארגונית שברמה העליונה.
- בוחרים אפשרות לאיכות הווידאו:
- התאמה אוטומטית (ברירת מחדל) – רוחב הפס מותאם לתנאי הרשת והמערכת כדי לספק את האיכות הטובה ביותר האפשרית.
- רוחב פס מוגבל לווידאו – רוחב הפס להעברת וידאו מוגבל ל-1 Mbps.
- אודיו בלבד – העברת הווידאו מושבתת כברירת מחדל. המשתמשים יכולים ללחוץ על
כדי להפעיל את המצלמה שלהם בחלון הדפדפן של Meet. המהירות להעברת הווידאו תוגבל ל-1 Mbps.
- מחילים את ההגדרות:
- אם ההגדרה היא ליחידה הארגונית ברמה העליונה, לוחצים על שמירה.
- אם ההגדרה היא ליחידת בת ארגונית והיא שונה מזו של ההורה, לוחצים על שינוי.
באמצעות Wi-Fi
ההמלצות הבאות רלוונטיות לסביבות משרדיות אופייניות. מהנדס של תוכנה אלחוטית צריך לבצע הערכה לגבי סביבות מורכבות יותר כמו:
- סביבות ייצור במפעלים
- אזורים עם רמות גבוהות של רעש תדרי רדיו
- אזורים שבהם הכיסוי האלחוטי נמוך
חשוב לקרוא בעיון את השיקולים הבאים בזמן התכנון, הפריסה וההפעלה של הרשתות האלחוטיות שמיועדות לשמש את Meet.
תדרי רדיו של 2.4 GHz לעומת 5 GHz
אנחנו ממליצים שהרשת תאלץ את הלקוחות לעבור לתדר רדיו של 5 GHz, אם הוא זמין.
מומלץ לא לפרוס ולא להפעיל את Meet באמצעות תדר רדיו של 2.4 GHz של רשת אלחוטית, כי בדרך כלל התדר הזה עמוס מאוד. בנוסף, תדר 2.4 GHz פחות מהימן כי יש בו 3 ערוצים לא חופפים, רמות רעש גבוהות והפרעות נוספות.
שיקולים לגבי התכנון והפריסה
לרשת האלחוטית, כדאי להביא בחשבון את הקיבולת ולא את הכיסוי.
- ניהול גודל התא – צריך לשלוט בגודל התא באמצעות עוצמת השידור של נקודת הגישה (AP). כדי להגדיל את הקיבולת, כדאי לפרוס תאים קטנים יותר במקומות שבהם צפויים להיות יותר מכשירים, כמו חדרי ישיבות ואולמות. כדי לספק כיסוי כללי בקומת המשרד, צריך להשתמש בתאים גדולים יותר.
- השביתו שימוש בשיעורי תעבורה נמוכים כדי לשפר את יעילות השימוש בתדרי רדיו – וכדי לאלץ את הלקוח לעבור ל-AP הקרוב ביותר בזמן נדידה בין נקודות AP.
- נהלו את הרשת באופן ריכוזי — כדי לאפשר שימוש בתכונות מתקדמות כמו נדידה חלקה בין נקודות גישה וניהול תקין של תדרי רדיו, צריך לנהל ולהפעיל רשת אלחוטית באופן ריכוזי. לא כדאי לנהל את הרשת כאוסף של נקודות AP עצמאיות.
- בדיקת הרשת האלחוטית אחרי הפריסה – חשוב לוודא שיש כיסוי אלחוטי במרחבים שבהם משתמשים בדרך כלל ב-Meet.
שימוש ב-WMM
כדי לאפשר תקשורת מהימנה ב-Meet באמצעות רשתות אלחוטיות, צריך להטמיע תוספי מולטימדיה אלחוטיים (WMM).
צריך לסווג את התנועה ב-Meet באחת מהדרכים הבאות:
- הבקר האלחוטי או ה-AP על סמך הפרוטוקולים והיציאות הספציפיים ל-Meet.
- ערך השדה 'מיקום התו (code point) לשירותים מבודלים' (DSCP) שהוגדר על ידי ציוד רשת אחר. אם הרשת מספיק מהימנה לדעתכם, השתמשו ב-DSCP.
כדי לספק איכות שירות (QoS) דו-כיוונית נדרשת תמיכה מלאה ב-WMM. למרות זאת, אפשר להגדיר זאת ברמת הרשת ועדיין לקבל יתרונות משמעותיים. התנועה ב-Meet צריכה להיות מוקצית לתור האודיו או הווידאו בבקר או ב-AP האלחוטי. התנועה ב-Meet צריכה לקבל עדיפות על פני סוגי תנועה אחרים.
שימוש ב-VDI
סביבות 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
מומלץ שלא להשתמש בשרתי proxy לתנועה ב-Meet. שימוש בשרת proxy לתנועה מאריך את זמן הטעינה, ולכן עלול להפחית את איכות הווידאו.
אם צריך להשתמש בשרתי proxy ברשת
אם אתם חייבים להשתמש בשרת proxy, חשוב שתזכרו ששרתי proxy יכולים להשפיע בצורה משמעותית על הביצועים. עליכם לוודא:
- שיש גישה לתנועה ב-Meet בהגדרה של שרת ה-proxy.
- שמערכת Meet משתמשת בהגדרות לשרת proxy של Chrome.
- שהרשת עוקפת את שרת ה-proxy לכתובת ה-IP וה-SNI של Meet.
פרוטוקול האינטרנט Socket Secure (SOCKS5) לא נתמך בשלב הזה.
אל תשתמשו ב-QoS
מומלץ שלא להשתמש בתכונה 'איכות השירות (QoS)' לתנועה ב-Meet. כדאי להשתמש ב-QoS רק במקרים הבאים:
- אם יש לכם סיבה טובה לכך, למשל רשת עמוסה
- אם אתם יכולים לפרוס ולתחזק מודל QoS מקצה לקצה ברשת.
אם אתם חייבים להשתמש ב-QoS
אל תשתמשו ב-VPN
מומלץ שלא להשתמש ב-VPN לתנועה ב-Meet. שימוש ברשתות VPN מאריך את זמן האחזור, ועלול לגרום למערכת Meet להפחית את איכות הווידאו והאודיו.
אם אתם חייבים להשתמש ב-VPN:
- הפעלה של מנהור מפוצל ל-VPN
- נתבו את הדומיינים משלב 2 אל מחוץ ל-VPN באמצעות ה-DNS או ה-SNI (מומלץ להשתמש ב-SNI).
- נתבו את הטווחים של כתובות ה-IP משלב 3 מחוץ ל-VPN באמצעות התאמת קידומת.
נושאים קשורים
Google, Google Workspace וסימנים וסמלי לוגו קשורים הם סימנים מסחריים של Google LLC. כל שמות החברות והמוצרים האחרים הם סימנים מסחריים של החברות שאליהן הם משויכים.