Optimera nätverket för Voice

En molnvänlig nätverksinfrastruktur gör att Voice-trafik kan kommunicera effektivt med Google-infrastrukturen. Gör så här:

• Se till att Voice-trafiken har en kort väg till internet. Undvik:
  • Proxyer
  • Paketinspektion eller protokollanalysatorer
• Mät och optimera:
  • Fördröjning: max 150 ms enkelriktad fördröjning (ITU G114)
  • Bandbredd: 50 kBps rekommenderas
  • Wi-Fi-nätverk: Se metodtips för Wi-Fi

Vi rekommenderar starkt att du inte använder proxyservrar för Voice-trafik i nätverket.

• Placera Voice-trafik på en godkännandelista i proxykonfigurationen.
• Voice har inte TCP som reservlösning, vilket Google Meet har. I Voice används enbart UDP för rösttrafik.
• Om proxy används för trafiken tillför det latens och kan göra att ljudkvaliteten reduceras automatiskt i Voice. Voice-prestandan är optimal när latensen mellan klienten och Googles backend är lägre än 100 ms.
• Internetprotokollet Socket Secure (SOCKS5) stöds inte.

Använd inte paketinspektion eller protokollanalysatorer för Voice om det är möjligt. De ger latens som kan göra att Voice-infrastrukturen automatiskt sänker ljudkvaliteten.

Paketinspektion av ljudtrafik ger inte heller mycket nytta eftersom automatiska skanningsverktyg inte kan rekonstruera ljudstreamdata.

Om dessa verktyg används lägger du till alla portnummer för Voice-trafik på en godkännandelista för att kringgå verktygen.

Följande rekommendationer gäller för normala kontorsmiljöer. En ingenjör med kunskap inom trådlösa nätverk bör utvärdera varje enskilt fall i mer komplexa miljöer, exempelvis för produktionsutrymmen, områden med höga nivåer av RF-brus eller utrymmen med dålig täckning.

Att köra realtidsappar i ett trådlöst nätverk kan vara krävande eftersom det underliggande RF-spektret och bandbredden delas mellan alla enheter som använder den.

Läs följande noggrant under utformning, implementering och användning av trådlösa nätverk med Voice.

2,4 GHz jämfört med 5 GHz RF-band

Vi rekommenderar i allmänhet att realtidsappar inte implementeras och drivs via det (vanligtvis kraftigt använda) 2,4 GHz-bandet i ett trådlöst nätverk. Den här rekommendationen omfattar program som ger anslutning i en vanlig kontorsmiljö.

2,4 Ghz-bandet är problematiskt eftersom det bara har tre icke-överlappande kanaler, normalt höga störningsnivåer från närliggande nätverk och extra störningar från andra enheter (exempelvis mikrovågor), vilket skapar en brusig och komplex RF-miljö.

Tillförlitlig drift av realtidsapplikationer som Voice beror på tillräcklig kapacitet, fördröjning, jitter och paketförlustnivåer, vilket är nästan omöjligt att uppnå över 2, 4 GHz-bandet.

Att tänka på vid design och implementering

Om du utformar ett trådlöst nätverk med stöd för realtidsapplikationer ska du tänka på kapaciteten snarare än täckningen.

• Hantera cellstorleken, vilken styrs av sändningseffekten hos åtkomstpunkten (AP). Implementera mindre celler där fler enheter förväntas, till exempel mötesrum och aulor, för att öka kapaciteten. Större celler kan ge allmän täckning i kontorsutrymmen.
• Inaktivera låga priser för att förbättra effektiviteten hos RF-användningen. Detta tvingar en klientöverlämning till närmaste AP vid roaming mellan AP:n.

Om ett SSID för ett trådlöst nätverk är tillgängligt på båda banden (2,4 GHz och 5 GHz) ska nätverket implementera aggressiv bandstyrning för att tvinga klienterna på 5 GHz-bandet.

• En realistisk förväntan är högst tio fasta telefoner anslutna till samma åtkomstpunkt. Ett högre antal kan skapa en oförutsägbar användarupplevelse.
• Trådlöst anslutna fasta telefoner ska inte användas av team med hög täthet/många röstsamtal, till exempel representanter eller supportteam. Exempel är webbplatser för myndigheter eller callcenter som är öppna dygnet runt.
• Korta röstavbrott på mindre än tio sekunder kan förväntas och kan inte elimineras på nätverksnivå för fasta telefoner som är anslutna trådlöst. Vi rekommenderar inte trådlösa nätverk för viktiga telefonsamtal, till exempel konferenser, pressmöten eller samtal med företagsledare.
• Även om reglerna varierar mellan länder/regioner, är det vanligt att Wi-Fi-enheter exempelvis använder DFS-kanaler för att inte störa ditt lokala väderradarsystem. Därför kommer en AP-enhet med radarinterferens att lämna kanalen. Alla klienter måste ansluta till en annan AP på en annan kanal.

För att tillåta avancerade funktioner, till exempel sömlös roaming mellan AP:er och korrekt RF-hantering, ska ett trådlöst nätverk hanteras och drivas centralt – inte som en samling siloplacerade, fristående AP:er.

Utför slutligen en kontroll efter implementeringen för att bekräfta trådlös täckning i de utrymmen där Voice vanligtvis används.

Voice-trafiken är skyddad och krypterad så det finns inget behov av att begränsa trafiken till Googles IP-adresser.

Om du har nätverksbegränsningar som kräver att du begränsar trafiken lägger du till följande uppsättning IP-intervall på en godkännandelista för att tillåta Voice-medieservrar. IP-adresserna används exklusivt för Voice för Google Workspace så att du kan identifiera rösttrafik som används i Google Workspace och prioritera ned Voice-trafik från konsumentkonton. Detta kan hjälpa dig att bättre konfigurera och optimera nätverks- och brandväggsåtkomst.

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

Ställ in nätverket så att följande portar tillåter rösttrafik att flöda till och från organisationen:

• utgående UDP-portar 19302 till 19309
• Utgående TCP-port 443

Obs! Voice-portintervallet 19302 till 19309 använder inställningen för Chrome WebRTC UDP-portar. Mer information finns i Konfigurera Chrome-policyer för användare eller webbläsare.