Optimera ditt nätverk för röst

En molnvänlig nätverksinfrastruktur gör det möjligt för rösttrafik att kommunicera effektivt med Googles infrastruktur. För att skapa detta:

• Se till att rösttrafik har en kort väg till internet. Undvik:
  • Proxyservrar
  • Paketinspektion eller protokollanalysatorer
• Mät och optimera:
  • Latens: max 150 ms enkelriktad fördröjning ( ITU G114 )
  • Bandbredd: 50 kbps rekommenderas
  • Wi-Fi-nätverk: Se bästa praxis för WiFi

Vi rekommenderar starkt att ditt nätverk inte använder proxyservrar för rösttrafik:

• I proxykonfigurationen, sätt rösttrafik på en tillåtelselista.
• Voice använder inte TCP som en reservfunktion, vilket Google Meet gör. Voice använder endast UDP för rösttrafik.
• Proxytrafik ökar latensen och kan göra att Voice automatiskt minskar ljudkvaliteten. 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 om möjligt inte paketinspektion eller protokollanalysatorer för röstkommunikation. De introducerar latens som kan få röstinfrastrukturen att automatiskt minska ljudkvaliteten.

Paketinspektion av ljudtrafik ger också liten nytta eftersom automatiserade skanningsverktyg inte kan rekonstruera ljudströmsdata.

Om dessa verktyg används, lägg till alla portnummer för rösttrafik på en lista med tillåtna platser för att kringgå verktygen.

Följande rekommendationer gäller för typiska kontorsmiljöer. En trådlös tekniker bör utvärdera mer komplexa miljöer från fall till fall, såsom tillverkningsgolv, områden med höga nivåer av radiofrekvensbrus (RF) eller glest täckta utrymmen.

Att köra realtidsapplikationer över ett trådlöst nätverk kan vara utmanande eftersom det underliggande RF-spektrumet och bandbredden delas mellan alla enheter som använder det.

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

2,4 GHz kontra 5 GHz RF-band

Vi rekommenderar generellt att realtidsapplikationer inte driftsätts och drivs över det (vanligtvis flitigt använda) 2,4 GHz-bandet i ett trådlöst nätverk. Denna rekommendation inkluderar applikationer som tillhandahåller anslutning i en vanlig kontorsmiljö.

2,4 GHz-bandet är problematiskt eftersom det bara har tre icke-överlappande kanaler, vanligtvis höga brusnivåer från närliggande störande nätverk och extra störningar från andra enheter (till exempel mikrovågsugnar), vilket skapar en bullrig och komplex RF-miljö.

Tillförlitlig drift av realtidsapplikationer som röst är beroende av tillräckliga nivåer av kapacitet, fördröjning, jitter och paketförlust, vilka är nästan omöjliga att uppnå över 2,4 GHz-bandet.

Design-/distributionsöverväganden

Om du utformar ett trådlöst nätverk för att stödja realtidsapplikationer, tänk på kapacitet snarare än täckning.

• Hantera cellstorleken, som styrs 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. Större celler kan ge generell täckning på kontorsgolvet.
• Inaktivera låga rater för att förbättra effektiviteten i RF-användningen. Detta tvingar en klient att överlämna till närmaste åtkomstpunkt vid roaming mellan åtkomstpunkter.

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

• En realistisk förväntan är att det inte är fler än 10 bordstelefoner anslutna till samma åtkomstpunkt. Ett större antal kan skapa en oförutsägbar användarupplevelse.
• Trådlösa bordstelefoner bör inte användas av team med hög densitet/många röstsamtal, såsom agenter eller supportteam. Till exempel GOVO-platser eller callcenter dygnet runt.
• Korta röstavbrott, kortare än 10 sekunder, är att förvänta och kan inte elimineras på nätverksnivå för trådlöst anslutna bordstelefoner. Vi rekommenderar inte trådlösa nätverk för att ringa högprofilerade telefonsamtal, såsom konferenser, pressmöten eller samtal med chefer.
• Även om reglerna varierar mellan länder/regioner är ett vanligt krav att Wi-Fi-enheter som använder DFS-kanaler inte stör exempelvis ditt lokala väderradarsystem. Som ett resultat kommer en accesspunkt som utsätts för radarstörningar att lämna kanalen. Alla klienter måste återansluta till en annan accesspunkt som använder en annan kanal.

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 – inte en samling isolerade, fristående accesspunkter.

Slutligen, utför en trådlös undersökning efter driftsättning för att bekräfta trådlös täckning i de utrymmen där röstkommunikation vanligtvis används.

Rösttrafiken är säker och krypterad, så det finns inget behov av att begränsa trafiken till Googles IP-adresser.

Om du däremot har nätverksbegränsningar som kräver att du begränsar trafiken, placera följande uppsättning IP-intervall på en tillåtelselista 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 nedprioritera rösttrafik 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

Konfigurera ditt nätverk så att följande portar tillåter rösttrafik att flöda till och från din organisation:

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

Obs! Röstportintervallet 19302 till 19309 använder Chrome WebRTC UDP-portsinställningen. Om du vill veta mer kan du läsa Ställ in Chrome-policyer för användare eller webbläsare .