Optimera nätverket för Voice

Här är några rekommenderade metoder för att konfigurera nätverket för Google Voice-samtal.

Skapa ett molnvänligt nätverk

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:

Bästa metoder för proxyer

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

  • Lägg till Voice-trafik på en godkännandelista i proxykonfigurationen.
  • Voice använder inte TCP som alternativ, vilket Google Meet gör. 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 Google-servern är lägre än 100 ms.
  • Internetprotokollet Socket Secure (SOCKS5) stöds inte.

Paketinspektion/protokollanalysatorer

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 minskar ljudkvaliteten.

Paketinspektion av ljudtrafik ger också liten fördel eftersom automatiska skanningsverktyg inte kan rekonstruera ljudstreamdata.

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

Bästa metoder för Wi-Fi

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 och 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 appar som tillhandahåller 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 realtidsappar som Voice är beroende av tillräcklig kapacitet, fördröjning, jitter och paketförlustnivåer, vilket är nästan omöjligt att uppnå via 2, 4 GHz-bandet.

Utformning 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äntning är att högst tio fasta telefoner är anslutna till samma AP. Ett större antal kan skapa en oförutsägbar användarupplevelse.
  • Trådlöst anslutna fasta telefoner ska inte användas av team med hög densitet/många röstsamtal, till exempel agenter eller supportteam. Exempel: GOVO-webbplatser eller callcenter som är öppna dygnet runt.
  • Korta röststörningar på mindre än tio sekunder kan förväntas och kan inte elimineras på nätverksnivå för trådlöst anslutna fasta telefoner. Vi rekommenderar inte trådlösa nätverk för viktiga telefonsamtal, till exempel konferenser, pressmöten eller samtal med chefer.
  • Ä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.

IP-adressintervall för Voice

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

Portintervall för Voice

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. Läs mer i Konfigurera Chrome-policyer för användare eller webbläsare.