Förbered ditt nätverk för Meet-möten och livestreams

Uppdatera dina brandväggar för att tillåta medietrafik att flöda till och från din organisation:

• För ljud och video, konfigurera utgående UDP-portar 3478 och 19302–19309.
  • Om du vill begränsa antalet Chrome WebRTC-portar som används, använd portarna som anges i WebRTC UDP-portar .
  • Eller så kan du begränsa dessa portar med din brandvägg.
• För webbtrafik och användarautentisering, använd utgående UDP och TCP-port 443.

Portarna är tillåtna utan någon IP-gräns. Om UDP-portar blockeras kommer TCP att användas. Användning av TCP eller proxy-TCP kan minska den totala möteskvaliteten.

Meet behöver fullständig nätverksåtkomst.

1. Om det finns begränsningar eller filtreringspolicyer för användare i ditt nätverk, ge nätverksåtkomst till URI-mönstren nedan på den här sidan med hjälp av port 443.
2. Om du använder Google Meet-maskinvara, granska nätverkskraven för ChromeOS under Konfigurera TLS-inspektion (eller SSL) på Chrome-enheter .

Domäner för statiska resurser

• clients2.google.com
• clients4.google.com
• clients6.google.com
• www.gstatic.com
• fonts.gstatic.com
• lh3.googleusercontent.com
• möten.klienter6.google.com

Domäner för API-slutpunktsanslutning

• accounts.google.com
• apis.google.com
• möten.googleapis.com
• hangouts.googleapis.com
• meet.google.com
• apps.google.com
• docs.google.com

Domäner för livestreaming

• meet.google.com
• stream.meet.google.com

Domäner för användarfeedback och uppladdningar av händelseloggar

• https://www.google.com/tools/feedback
• https://feedback.googleusercontent.com/resources/
• https://play.google.com/log

1. Om din organisation måste ha stöd för Meet-trafik över port 443, lägg till Meet SNI i din brandväggs- eller proxylista för att aktivera ljud- och videotrafik över TLS. Dessa IP-adresser skiljer sig från de URI:er som anges i steg 2.
2. Lägg till IP-adressintervall för Google Workspace (för dina användare). Tillåt åtkomst till Meets medieservrar med följande uppsättning IP-intervall och 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
3. Om din organisation använder livestreaming med låg latens kommer trafik för livestreaming att föredras med UDP-protokollet. Denna trafik kommer att använda IP-intervallen för arbetsytan (liknande Meet) istället för YouTubes HTTP-IP-adresser.
4. Lägg till IP-adressintervall för konsumenter. Tillåt åtkomst till Meets medieservrar med följande uppsättning IP-intervall:
   • IPv4: 142.250.82.0/24
   • IPv6: 2001:4860:4864:6::/64
   • SNI: meet.turns.goog

Ditt nätverk bör ha tillräckligt med bandbredd för flera HD-videomöten. Det bör också ha extra bandbredd för andra behov, som livestreaming. Antal deltagare, skärmdelning och andra faktorer påverkar också bandbreddsanvändningen.

Om ditt nätverk inte har tillräckligt med bandbredd sänker Meet videoupplösningen. Om ditt nätverk inte har tillräckligt med bandbredd för att stödja video ställer du in Meet på Endast ljud.

För att streama med mindre bandbredd, vara värd för stora livestreamar med mindre bandbredd med hjälp av eCDN .

Beräkna minimikraven för Meet-bandbredd

För att beräkna den minsta bandbredd som behövs för din organisation, multiplicera den genomsnittliga bandbredden per deltagare med det högsta antalet samtidiga deltagare.

Många faktorer, som antal deltagare, layouter och skärmdelning, kan påverka bandbreddsanvändningen. Om en skärmdelning är stilla tar den inte upp mer bandbredd efter att den har laddats.

*Beroende på vilken upplösning som skickas

Uppskatta maximalt antal samtidiga deltagare

Om Meet-möten har hög prioritet, uppskatta att 20 % av användarna i din organisation kommer att använda Meet samtidigt. Om Meet-möten har låg prioritet kan endast 0,5 % av personerna vara i ett Meet-möte samtidigt.

Bandbreddskrav per livestream

Om din organisation livestreamar möten är den ideala bandbredden för varje visningsflöde 2,6 Mbps. Livestreamar har dynamiska layout- och storleksalternativ. Enhetsfunktioner som fönsterstorlek och bildförhållande är optimerade. Meet använder standardinställningen för högkvalitativ video om deltagaren har tillräckligt med individuell bandbredd.

Om tittarna inte har tillräckligt med bandbredd kan de välja att minska Meet-kvaliteten eller bara använda ljud.

Enskild videoruta (bithastighet kilobit/s)

Skärmdelningsruta (bithastighet kilobit/s)

Kvaliteten på liveströmmande media påverkas av medians ursprungliga kvalitet och hur media skickas till Meet. Du kan kontrollera och jämföra kvaliteten genom att delta i Meet-samtalet för liveströmmen som en vanlig deltagare.

1. I Googles administratörskonsol, gå till Meny Appar Google Workspace Google Meet .

   Gå till Google Meet

   Kräver administratörsbehörighet för tjänstinställningar .

2. Klicka på Meet-videoinställningar .
3. Till vänster väljer du den organisationsenhet du vill hantera. För alla användare väljer du den översta organisationsenheten.
4. Välj ett alternativ för videokvalitet:
   • Justera automatiskt (standard) – Bandbredden justeras efter nätverks- och systemförhållanden för att ge bästa möjliga kvalitet.
   • Begränsad videobandbredd — Upplänksbandbredden är begränsad till 1 Mbps.
   • Endast ljud – Video är avstängt som standard. Användare kan klicka för att slå på kameran i Meet-webbläsarfönstret. Upplänksvideo kommer att begränsas till 1 Mbit/s.
5. Tillämpa inställningarna:
   1. Om inställningen gäller den övergripande organisationsenheten klickar du på Spara .
   2. Om inställningen gäller en underordnad organisationsenhet och skiljer sig från den överordnade klickar du på Åsidosätt .

Följande rekommendationer gäller för typiska kontorsmiljöer. En trådlös tekniker bör utvärdera mer komplexa miljöer, såsom:

• Tillverkningsgolv
• Områden med höga nivåer av radiofrekvent brus
• Glestäckta utrymmen

Granska noggrant följande överväganden vid design, driftsättning och drift av trådlösa nätverk som används av Meet.

2,4 GHz kontra 5 GHz RF-band

Vi rekommenderar att ditt nätverk tvingar klienter över till 5 GHz RF-bandet, om tillgängligt.

Vi rekommenderar att du inte distribuerar och använder Meet över 2,4 GHz-bandet i ett trådlöst nätverk eftersom det ofta används flitigt. 2,4 GHz-bandet är också mindre tillförlitligt eftersom det har 3 icke-överlappande kanaler, höga brusnivåer och extra störningar.

Design- och driftsättningsöverväganden

För ditt trådlösa nätverk, tänk på kapacitet snarare än täckning.

• Hantera cellstorlek — Kontrollera cellstorleken med hjälp av accesspunktens (AP) sändningseffekt. Implementera mindre celler där fler enheter förväntas, till exempel mötesrum och auditorier, för att öka kapaciteten. Använd större celler för att ge generell täckning på ett kontorsgolv.
• Inaktivera låga rater för att förbättra RF-användningseffektiviteten — Tvinga en klients överlämning till närmaste åtkomstpunkt vid roaming mellan åtkomstpunkter.
• Hantera ditt nätverk centralt – För att möjliggöra avancerade funktioner, som sömlös roaming mellan accesspunkter och korrekt RF-hantering, bör ett trådlöst nätverk hanteras och drivas centralt. Det bör inte vara en samling fristående accesspunkter.
• Utför en undersökning av trådlöst nätverk efter driftsättning — Bekräfta trådlös täckning i de utrymmen där Meet vanligtvis används.

Använda WMM

För att stödja tillförlitlig Meet-kommunikation över trådlösa nätverk bör du implementera Wireless Multimedia Extensions (WMM).

Meet-trafik måste klassificeras på ett av följande sätt:

• Den trådlösa handkontrollen eller AP:n baserad på Meet-specifika protokoll och portar.
• Värdet för fältet Differentiated Services Code Point (DSCP) som ställts in av annan nätverksutrustning. Använd DSCP om du har tillräckligt förtroende för nätverket.

Fullt WMM-stöd krävs för att tillhandahålla dubbelriktad Quality of Service (QS). Du kan dock konfigurera det på nätverksnivå för betydande fördelar. Meet-trafik bör tilldelas ljud- eller videokön på den trådlösa åtkomstpunkten eller kontrollenheten. Meet-trafik bör föredras framför andra trafikklasser.

VDI-miljöer skapar ett extra lager mellan Meet och internet. Detta kan göra Meet långsammare och resultera i en upplevelse av lägre kvalitet. Bakgrundseffekter är begränsade och förhandsgranskning av greenroom är inte tillgänglig.

För att minska påverkan av VDI-användning på Meet kan du vidta följande steg:

• Säkerställ att Google Meet kan upptäcka att det körs inuti en virtuell maskin (VM) genom att aktivera Enterprise Hardware Platform API-policyn i Chrome. Mer information finns i Ange Chrome-policyer för användare eller webbläsare och API-sidan .
• Allokera minst fyra virtuella processorer för varje virtuell maskininstans.
• En GPU krävs inte för bakgrundseffekter, men GPU-aktiverade VM-instanser ökar tillförlitligheten.
• Säkerställ tillräcklig bandbredd och låg latens mellan klienter, virtuella skrivbord och Meet-medieservrar. För bandbreddskrav mellan Meet-medieservrar och virtuella maskiner, se steg 4 (ovan på den här sidan). Ta reda på den bandbredd som krävs för anslutningen mellan VDI-klienter och virtuella maskiner genom att kontakta din VDI-leverantör.

Bästa praxis är att inte använda proxyservrar för Meet-trafik. Proxytrafik ökar latensen vilket kan orsaka minskad videokvalitet.

Om proxyservrar måste användas i ditt nätverk

Om du behöver använda en proxy, var medveten om att proxyservrar kan påverka prestandan kraftigt och se till att:

• För att tillåta åtkomst till Meet-trafik i proxykonfigurationen.
• Meet använder Chromes proxyinställningar .
• Nätverket kringgår proxyn för Meet IP-adress och SNI .

Internetprotokollet Socket Secure (SOCKS5) stöds för närvarande inte.

Bästa praxis är att inte använda servicekvalitet (QoS) för Meet i ditt nätverk. Använd endast QoS om:

• Du har en tvingande anledning, till exempel ett överbelastat nätverk
• kan distribuera och underhålla en heltäckande QoS-modell i ditt nätverk.

Om du måste använda QoS

Bästa praxis är att inte använda VPN för Meet-trafik. VPN ökar latensen och kan få Meet att minska video- och ljudkvaliteten.

Om du måste använda ett VPN:

• Aktivera split tunneling för ditt VPN
• Dirigera domänerna från steg 2 utanför VPN:et med hjälp av DNS eller SNI (SNI rekommenderas)
• Dirigera IP-intervallen från steg 3 utanför VPN:et via prefixmatchning