Hier volgen enkele praktische tips om uw netwerk in te stellen voor Voice-gesprekken:
Een cloud-vriendelijk netwerk maken
Met een cloud-vriendelijke netwerkinfrastructuur kan Voice-verkeer efficiënt communiceren met de Google-infrastructuur. Ga als volgt te werk om deze infrastructuur te maken:
- Zorg dat Voice-verkeer een kort pad naar het internet heeft. Gebruik het volgende niet:
- Proxy's
- Pakketinspectie- of protocolanalyseprogramma's
- Meet en optimaliseer de volgende items:
- Wachttijd: maximaal 150ms vertraging één kant op (ITU G114)
- Bandbreedte: 50 kbps wordt aanbevolen
- Wifi-netwerk: zie Praktische tips voor wifi
Praktische tips voor proxy's
We raden het gebruik van proxyservers in uw netwerk voor Voice-verkeer sterk af:
- Zet Voice op de witte lijst in de proxyconfiguratie.
- Voice gebruikt TCP niet als reserve, zoals Meet. Voice gebruikt alleen UDP voor spraakverkeer.
- Wanneer verkeer via een proxy verloopt, zorgt dit voor een langere wachttijd. Hierdoor kan het voorkomen dat Voice de audiokwaliteit automatisch vermindert. De prestaties van Voice zijn optimaal wanneer de wachttijd tussen de client en de Google-backend minder dan 100 ms is.
- Het Socket Secure-internetprotocol (SOCKS5) wordt niet ondersteund.
Pakketinspectie- of protocolanalyseprogramma's
Gebruik indien mogelijk geen pakketinspectie- of protocolanalyseprogramma's voor Voice. Deze zorgen voor langere wachttijden, waardoor de Voice-infrastructuur automatisch de audiokwaliteit vermindert.
Pakketinspectie biedt ook weinig voordeel bij audioverkeer, omdat automatische scantools geen gegevens kunnen ophalen uit de audiostroom.
Als u deze tools wel gebruikt, moet u de poortnummers voor Voice-verkeer op de witte lijst zetten, zodat deze tools worden overgeslagen.
Praktische tips voor wifi
De volgende aanbevelingen gelden voor typische kantooromgevingen. Complexere omgevingen, zoals fabrieksvloeren, gebieden met veel ruis op de radiofrequentie (RF) of gebieden met weinig dekking, moeten individueel worden geëvalueerd door een wifi-technicus.
Het kan lastig zijn realtime apps te gebruiken op een draadloos netwerk, omdat het onderliggende RF-spectrum en de bandbreedte worden gedeeld door alle apparaten die het netwerk gebruiken.
Bekijk de volgende overwegingen wanneer u een draadloos netwerk ontwerpt, implementeert en gebruikt met Voice.
2,4 GHz- en 5 GHz RF-banden
We raden het over het algemeen af realtime apps te implementeren en gebruiken met de (meestal zwaarbelaste) 2,4 GHz-band van een draadloos netwerk. Dit zijn ook de internetnetwerken die worden gebruikt in normale kantooromgevingen.
De 2,4 Ghz-band is niet goed voor Voice-verkeer, omdat deze slechts drie niet-overlappende kanalen bevat en er hoge ruisniveaus van nabijgelegen storende netwerken en extra storing aanwezig is van andere apparaten (bijvoorbeeld magnetronovens), waardoor een lawaaierige en complexe RF-omgeving ontstaat.
Realtime apps als Voice werken alleen betrouwbaar als er genoeg capaciteit en weinig vertraging, ruis en pakketverlies is. Dit is bijna onmogelijk te bereiken via de 2,4 GHz-band.
Overwegingen voor ontwerp en implementatie
Als u een draadloos netwerk ontwerpt dat realtime apps moet ondersteunen, houd dan vooral rekening met capaciteit in plaats van dekking.
- Beheer de celgrootte, die wordt bepaald door de zendkracht van het toegangspunt (Access Point, AP). Implementeer kleinere cellen wanneer u meer apparaten verwacht, zoals vergaderruimten en collegezalen, voor meer capaciteit. Grotere cellen zijn geschikt voor algemene dekking op kantoor.
- Schakel lage rates uit om de RF efficiënter te gebruiken. De client voert dan een gedwongen overdracht uit naar de dichtstbijzijnde AP tijdens het roamen tussen AP's.
Als de SSID van een draadloos netwerk beschikbaar is op beide banden (2,4 GHz en 5 GHz), moet het netwerk agressieve band steering gebruiken, zodat clients worden gedwongen de 5 GHz-band te gebruiken.
- Een realistische verwachting is niet meer dan tien vaste telefoons aangesloten op hetzelfde TP. Een groter aantal kan ertoe leiden dat de prestaties verminderen.
- Draadloze telefoontoestellen worden afgeraden voor teams die veel gesprekken voeren, zoals agents of supportteams. Bijvoorbeeld GOVO-locaties of callcenters die 24 uur per dag, 7 dagen per week open zijn.
- Korte uitval van minder dan tien seconden is te verwachten en kan niet worden voorkomen op netwerkniveau voor vaste draadloze telefoons. Draadloze netwerken worden afgeraden voor belangrijke gesprekken. Bijvoorbeeld conferenties, persvoorlichtingen of telefonische meetings.
- Hoewel de regelgeving per land/regio verschilt, is het een veelvoorkomende vereiste dat wifi-apparaten die gebruikmaken van DFS-kanalen zorgen dat deze bijvoorbeeld niet het lokale weerradarsysteem verstoren. Als gevolg hiervan zal een TP dat een radarsysteem verstoort, het kanaal vrijgeven. Alle clients moeten opnieuw verbinding maken met een ander TP dat via een ander kanaal werkt.
Als u geavanceerde functies mogelijk wilt maken, zoals naadloze roaming tussen TP's en het juiste RF-beheer, moet een draadloos netwerk centraal worden beheerd en geen verzameling zijn van alleenstaande TP's.
Voer als laatste na de implementatie een test uit om te kijken of het draadloze netwerk genoeg dekking heeft in de ruimten waarin Voice het meeste zal worden gebruikt.
Het IP-adresbereik van Voice op de witte lijst zetten
Voice-verkeer is beveiligd en versleuteld. Het is dus niet nodig het verkeer naar de IP-adressen van Google te beperken.
Als er echter netwerkbeperkingen gelden die vereisen dat verkeer wordt beperkt, gebruikt u de volgende IP-bereiken om de mediaservers van Voice op de witte lijst te zetten. De IP-adressen worden alleen gebruikt voor Google Voice voor Google Workspace. Zo kunt u Voice-verkeer in Google Workspace identificeren en Voice-verkeer minder prioriteit geven dan verkeer van consumentenaccounts. U kunt dan de netwerk- en firewalltoegang beter instellen en optimaliseren.
- IPv4: 74.125.39.0/24
- IPv6: 2001:4860:4864:2::0/64
