Optimaliseer uw netwerk voor spraak.

Een cloudvriendelijke netwerkinfrastructuur zorgt ervoor dat spraakverkeer efficiënt kan communiceren met de Google-infrastructuur. Om dit te realiseren:

• Zorg ervoor dat spraakverkeer een korte route naar internet heeft. Vermijd:
  • Proxy's
  • Pakketinspectie of protocolanalysatoren
• Meten en optimaliseren:
  • Latentie: maximaal 150 ms vertraging in één richting ( ITU G114 )
  • Bandbreedte: 50 kbps aanbevolen
  • Wi-Fi-netwerk: Raadpleeg de beste praktijken voor wifi.

We raden ten zeerste af om proxyservers te gebruiken voor spraakverkeer binnen uw netwerk.

• Voeg in de proxyconfiguratie spraakverkeer toe aan een whitelist.
• Voice maakt geen gebruik van TCP als terugvaloptie, zoals Google Meet dat wel doet. Voice gebruikt uitsluitend UDP voor spraakverkeer.
• Het gebruik van een proxy voor het verkeer zorgt voor extra vertraging en kan ertoe leiden dat Voice de audiokwaliteit automatisch verlaagt. De prestaties van Voice zijn optimaal wanneer de vertraging tussen de client en de Google-backend lager is dan 100 ms.
• Het Socket Secure (SOCKS5) internetprotocol wordt niet ondersteund.

Gebruik indien mogelijk geen pakketinspectie of protocolanalysatoren voor spraak. Deze introduceren latentie die ertoe kan leiden dat de spraakinfrastructuur de audiokwaliteit automatisch verlaagt.

Pakketinspectie van audioverkeer levert ook weinig voordeel op, omdat geautomatiseerde scantools de gegevens van de audiostream niet kunnen reconstrueren.

Als deze tools worden gebruikt, voeg dan alle poortnummers voor spraakverkeer toe aan een whitelist om de tools te omzeilen.

De volgende aanbevelingen gelden voor typische kantooromgevingen. Een wireless engineer dient complexere omgevingen, zoals productiehallen, ruimtes met veel radiofrequentieruis (RF-ruis) of dunbevolkte ruimtes, per geval te beoordelen.

Het uitvoeren van realtime-applicaties via een draadloos netwerk kan een uitdaging zijn, omdat het onderliggende RF-spectrum en de bandbreedte worden gedeeld door alle apparaten die er gebruik van maken.

Neem de volgende aandachtspunten zorgvuldig door tijdens het ontwerpen, implementeren en beheren van draadloze netwerken die voor spraakdoeleinden worden gebruikt.

2,4 GHz versus 5 GHz RF-banden

Over het algemeen raden we af om realtime-applicaties te implementeren en te gebruiken via de (doorgaans veelgebruikte) 2,4 GHz-band van een draadloos netwerk. Deze aanbeveling geldt ook voor applicaties die connectiviteit bieden in een gewone kantooromgeving.

De 2,4 GHz-band is problematisch omdat deze slechts 3 niet-overlappende kanalen heeft, doorgaans hoge ruisniveaus van nabijgelegen interfererende netwerken en extra interferentie van andere apparaten (bijvoorbeeld microgolven), wat een lawaaierige en complexe RF-omgeving creëert.

De betrouwbare werking van realtime-applicaties zoals spraak is afhankelijk van voldoende capaciteit, vertraging, jitter en pakketverlies, wat vrijwel onmogelijk te bereiken is in de 2,4 GHz-band.

Ontwerp-/implementatieoverwegingen

Als je een draadloos netwerk ontwerpt ter ondersteuning van realtime-applicaties, denk dan aan capaciteit in plaats van bereik.

• Beheer de celgrootte, die wordt bepaald door het zendvermogen van het toegangspunt (AP). Plaats kleinere cellen waar meer apparaten worden verwacht, zoals in vergaderruimtes en auditoria, om de capaciteit te vergroten. Grotere cellen kunnen algemene dekking bieden op de kantoorverdieping.
• Schakel lage snelheden uit om de efficiëntie van het RF-gebruik te verbeteren. Hierdoor wordt een client gedwongen over te schakelen naar het dichtstbijzijnde toegangspunt tijdens het roamen tussen toegangspunten.

Als de SSID van een draadloos netwerk beschikbaar is op beide frequentiebanden (2,4 GHz en 5 GHz), moet het netwerk agressieve bandsturing toepassen om clients te dwingen de 5 GHz-band te gebruiken.

• Een realistische verwachting is dat er niet meer dan 10 bureautelefoons op hetzelfde toegangspunt (AP) aangesloten kunnen zijn. Een groter aantal kan leiden tot een onvoorspelbare gebruikerservaring.
• Draadloos verbonden bureautelefoons zijn niet geschikt voor teams met een hoge dichtheid aan spraakoproepen, zoals agenten of supportteams. Denk bijvoorbeeld aan GOVO-locaties of 24/7 callcenters.
• Korte spraakonderbrekingen van minder dan 10 seconden zijn te verwachten en kunnen niet op netwerkniveau worden geëlimineerd bij draadloos verbonden vaste telefoons. We raden draadloze netwerken niet aan voor het voeren van belangrijke telefoongesprekken, zoals conferenties, persconferenties of gesprekken met directieleden.
• Hoewel de regelgeving per land/regio verschilt, is een veelvoorkomende vereiste dat wifi-apparaten gebruikmaken van DFS-kanalen om te voorkomen dat ze bijvoorbeeld het lokale weerradarsysteem verstoren. Als gevolg hiervan zal een access point dat last heeft van radarinterferentie het kanaal verlaten. Alle clients moeten dan opnieuw verbinding maken met een ander access point dat op een ander kanaal werkt.

Om geavanceerde functies mogelijk te maken, zoals naadloos schakelen tussen access points en goed RF-beheer, moet een draadloos netwerk centraal beheerd en geëxploiteerd worden – en niet bestaan ​​uit een verzameling losstaande access points.

Voer tot slot na de implementatie een draadloze dekkingsmeting uit om de draadloze dekking te bevestigen in alle ruimtes waar spraak doorgaans wordt gebruikt.

Het spraakverkeer is beveiligd en versleuteld, dus het is niet nodig om het verkeer te beperken tot de IP-adressen van Google.

Als u echter netwerkbeperkingen hebt waardoor u het verkeer moet beperken, kunt u de volgende IP-bereiken toevoegen aan een whitelist om spraakmediaservers toe te staan. Deze IP-adressen worden uitsluitend gebruikt voor spraak in Google Workspace, zodat u spraakverkeer binnen Google Workspace kunt identificeren en spraakverkeer van consumentenaccounts kunt deprioriteren. Dit kan u helpen bij het beter instellen en optimaliseren van netwerk- en firewalltoegang.

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

Configureer uw netwerk zodanig dat de volgende poorten spraakverkeer van en naar uw organisatie mogelijk maken:

• Uitgaande UDP-poorten 19302 tot 19309
• Uitgaande TCP-poort 443

Opmerking: Het spraakpoortbereik 19302 tot 19309 maakt gebruik van de Chrome WebRTC UDP-poortinstellingen. Lees Chrome-beleid instellen voor gebruikers of browsers voor meer informatie.