Das Netzwerk für Google Voice optimieren

Für eine effiziente Übertragung des Voice-Traffics zwischen Ihrem Netzwerk und der Google-Infrastruktur muss Ihr Netzwerk cloudfreundlich sein. Dies erreichen Sie so:

• Verbinden Sie Google Voice möglichst direkt mit dem Internet. Verzichten Sie dabei auf Folgendes:
  • Proxys
  • Tools für Paketprüfung/Protokollanalyse
• Folgende Bedingungen müssen erfüllt sein:
  • Latenz: maximal 150 ms unidirektionale Verzögerung (ITU G114)
  • Bandbreite: 50 kBit/s (empfohlen)
  • WLAN: Siehe die Best Practices für WLAN

Sie sollten für Voicetraffic in Ihrem Netzwerk auf keinen Fall Proxyserver verwenden:

• Setzen Sie den Voice-Traffic in der Proxykonfiguration auf eine Zulassungsliste.
• Voice bietet kein Fallback auf TCP wie Google Meet. Voice verwendet UDP nur für den Sprachtraffic.
• Proxys erhöhen die Latenz und können dazu führen, dass Voice automatisch die Audioqualität herabsetzt. Damit Voice optimal funktioniert, sollte die Latenz zwischen dem Client und dem Back-End von Google weniger als 100 ms betragen.
• Das Socket Secure-Internetprotokoll (SOCKS5) wird nicht unterstützt.

Verwenden Sie für Voice nach Möglichkeit keine Tools zur Paketprüfung oder Protokollanalyse. Sie erhöhen die Latenz, was dazu führen kann, dass die Voice-Infrastruktur die Audioqualität automatisch verringert.

Die Paketprüfung von Audiotraffic bringt ebenfalls wenig, da automatisierte Scantools die Daten des Audiostreams nicht rekonstruieren können.

Wenn Sie dennoch Tools zur Paketprüfung oder Protokollanalyse verwenden, sollten Sie alle Ports für Voicetraffic auf eine Zulassungsliste setzen, damit diese Tools umgangen werden.

Die folgenden Empfehlungen gelten für normale Büroumgebungen. Bei komplexeren Szenarien sollte ein Wireless Engineer von Fall zu Fall entscheiden. Dazu zählen z. B. Produktionsumgebungen sowie Bereiche mit hohem HF-Rauschen (Hochfrequenz) oder geringer Netzabdeckung.

Das Ausführen von Echtzeitanwendungen über ein drahtloses Netzwerk kann eine Herausforderung sein, da das zugrunde liegende HF-Spektrum und die Bandbreite von allen Geräten gemeinsam genutzt werden.

Bitte lesen Sie aufmerksam die folgenden Hinweise zum Entwerfen, Bereitstellen und Betreiben von drahtlosen Netzwerken, in denen Voice verwendet wird.

2,4‑GHz- vs.5‑GHz-HF-Band

Wir empfehlen generell, Echtzeitanwendungen nicht über das (normalerweise stark ausgelastete) 2,4-GHz-Band eines drahtlosen Netzwerks bereitzustellen und zu betreiben. Diese Empfehlung umfasst Anwendungen, die in einer normalen Büroumgebung für Konnektivität sorgen.

Das 2,4-GHz-Band ist problematisch, da es nur drei nicht überlappende Kanäle hat und störende Netzwerke in der Nähe üblicherweise zu einem hohen Rauschpegel führen. Andere Geräte wie Mikrowellen verursachen zusätzliche Interferenzen. So entsteht eine verrauschte und komplexe HF-Umgebung.

Der zuverlässige Betrieb von Echtzeitanwendungen wie Voice hängt von ausreichender Kapazität, Verzögerung, Jitter und Paketverlust ab, was über das 2, 4-GHz-Band fast unmöglich zu erreichen ist.

Hinweise zu Design und Bereitstellung

Wenn Sie ein drahtloses Netzwerk für Echtzeitanwendungen entwerfen, sollte die Kapazität eine größere Rolle spielen als die Abdeckung.

• Sie können die Größe der Funkzelle über die Sendeleistung des Zugriffspunkts (ZP) steuern. Kleinere Zellen sollten in Bereichen bereitgestellt werden, in denen Sie mehrere Geräte erwarten, z. B. in Konferenzräumen und Auditorien, denn sie erhöhen die Kapazität. In größeren Zellen kann das WLAN für eine Büroetage bereitgestellt werden.
• Niedrige Datenraten deaktivieren, um die HF-Nutzungseffizienz zu verbessern. Ein Client wird so gezwungen, das WLAN-Signal während des Roamings zwischen ZPs an den nächstgelegenen ZP zu übertragen.

Wenn die SSID eines drahtlosen Netzwerks sowohl auf dem 2,4-GHz- als auch auf dem 5-GHz-Band verfügbar ist, sollte im Netzwerk ein aggressives Band Steering implementiert werden, um zu erzwingen, dass Clients das 5-GHz-Band nutzen.

• Realistisch sind nicht mehr als 10 Festnetztelefone, die mit demselben AP verbunden sind. Eine größere Anzahl kann zu einer unvorhersehbaren Nutzererfahrung führen.
• Kabellos verbundene Festnetztelefone sollten nicht von Teams mit hoher Dichte/hohem Sprachanrufaufkommen verwendet werden, z. B. von Kundenservicemitarbeitern oder Supportteams. Beispiele hierfür sind GOVO-Websites oder Callcenter, die rund um die Uhr erreichbar sind.
• Kurze Sprachunterbrechungen von weniger als 10 Sekunden sind zu erwarten und können auf Netzwerkebene für drahtlos verbundene VoIP-Telefone nicht beseitigt werden. Wir empfehlen, für wichtige Telefonate wie Konferenzen, Pressetermine oder Anrufe von Führungskräften keine drahtlosen Netzwerke zu verwenden.
• Eine häufige Vorgabe, die jedoch je nach Land unterschiedlich sein kann, ist die Verwendung von DFS-Kanälen für WLAN-Geräte, damit beispielsweise nicht das lokale Wetterradarsystem beeinträchtigt wird. Infolgedessen wird ein ZP, der einer Radarinterferenz ausgesetzt ist, den Kanal verlassen. Alle Clients müssen sich neu mit einem anderen ZP verbinden, der auf einem anderen Kanal läuft.

Damit erweiterte Funktionen wie nahtloses Roaming zwischen ZPs und eine korrekte HF-Verwaltung möglich sind, sollte ein WLAN nicht aus mehreren eigenständigen ZPs bestehen, sondern zentral verwaltet und betrieben werden.

Erkundigen Sie sich nach der Bereitstellung, ob die Bereiche, in denen Voice normalerweise verwendet wird, auch wirklich vom WLAN abgedeckt werden.

Der Voicetraffic ist gesichert und verschlüsselt und muss daher nicht auf Google-IP-Adressen beschränkt werden.

Machen Netzwerkbeschränkungen an Ihrem Standort dies jedoch erforderlich, setzen Sie die folgenden IP-Bereiche auf die Zulassungsliste, um Voice-Medienserver zuzulassen. Die IP-Adressen werden ausschließlich für Voice für Google Workspace verwendet. So können Sie den in Google Workspace verwendeten Voicetraffic identifizieren und dem Voicetraffic von Privatnutzerkonten die Priorität entziehen. Das erleichtert Ihnen die Einrichtung und Optimierung des Netzwerk- und Firewallzugriffs.

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

Richten Sie das Netzwerk Ihrer Organisation so ein, dass über die folgenden Ports eingehender und ausgehender Voice-Datenverkehr zugelassen wird:

• Die ausgehenden UDP-Ports 19302 bis 19309
• Ausgehender TCP-Port: 443

Hinweis:Für den Voice-Portbereich 19302 bis 19309 wird die Chrome-Einstellung „WebRTC UDP-Ports“ verwendet. Weitere Informationen finden Sie im Hilfeartikel Chrome-Richtlinien für Nutzer oder Browser festlegen.