Här är några bra tips som hjälper dig konfigurera ditt nätverk för 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:
- Latens: max 150 ms envägsfördröjning (ITU G114)
- Bandbredd: 50 kBps rekommenderas
- Wi-Fi-nätverk: Se metodtips för Wi-Fi
Bästa metoder för proxyer
Vi rekommenderar starkt att du inte använder proxyservrar för Voice-trafik i nätverket.
- Vitlista Voice-trafik i proxykonfigurationen.
- Voice har inte TCP som alternativ på det sätt 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-prestanda ä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 introducerar latens som kan leda till att Voice-infrastrukturen automatiskt reducerar ljudkvaliteten.
Paketinspektion av ljudtrafik ger också små fördelar eftersom automatiska skanningsverktyg inte kan återskapa data från ljudflödet.
Om dessa verktyg används ska alla Voice-trafikportnummer vitlistas för att kringgå dem.
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. Detta inkluderar de 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ö.
Pålitlig drift av realtidsappar som Voice bygger på tillräcklig kapacitet, fördröjning, jitter och paketförlustnivåer. Dessa är nästan omöjliga att uppnå över 2,4 GHz-bandet.
Tänk på följande när det gäller design/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 överlämning till närmaste AP vid roaming mellan AP:er för en klient.
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 genomföra aggressiv bandstyrning för att tvinga klienterna på 5 GHz-bandet.
- En realistisk omfattning är att inte ansluta fler än 10 fasta telefoner till samma AP. Ett större antal kan skapa en oförutsägbar användarupplevelse.
- Trådlöst anslutna fasta telefoner får inte användas av team med hög densitet/många samtal, som agenter eller supportteam. Till exempel GOVO-platser eller callcenter som är öppna dygnet runt veckans alla dagar.
- Korta röstavbrott, mindre än 10 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 högprofilerade telefonsamtal. Exempelvis konferenser, pressmöten eller chefssamtal.
- Ä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.
Tillåta Voice IP-adressintervall
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 använder du följande uppsättning IP-intervall för att tillåta Voice-medieservrar. IP-adresserna används exklusivt för Google Voice for Google Workspace så att du kan identifiera rösttrafik som används i Google Workspace och prioritera ned Hangouts-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
