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. So erstellen Sie das:

• 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: max. 150 ms pro Richtung (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 Voicetraffic in der Proxykonfiguration auf die Zulassungsliste.
• Anders als in Google Meet wird bei Voice kein Fallback auf TCP ausgeführt. Bei Voice wird UDP nur für Voicetraffic verwendet.
• Wenn Sie für den Datenverkehr einen Proxy verwenden, erhöht sich die Latenz und die Audioqualität in Voice wird möglicherweise automatisch verringert. 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. Diese verursachen Latenzen, wodurch die Audioqualität in Voice möglicherweise automatisch verringert wird.

Eine Inspektion der Pakete des Audio-Traffics bringt auch kaum Vorteile, da automatische Scantools keine Audiostreams rekonstruieren können.

Wenn Sie dennoch Tools zur Paketprüfung oder Protokollanalyse verwenden, sollten Sie alle Ports für Voicetraffic auf die 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.

Echtzeitanwendungen lassen sich über WLAN nicht immer reibungslos ausführen, da das zugrunde liegende Funkfrequenzspektrum und die Bandbreite unter allen genutzten Geräten aufgeteilt werden.

Lesen Sie sich aufmerksam die folgenden Hinweise zum Entwerfen, Bereitstellen und Betreiben von für Voice verwendeten WLANs durch:

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

Wir empfehlen generell, Echtzeitanwendungen nicht über das oft verwendete 2,4-GHz-Band eines WLANs 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.

Echtzeitanwendungen wie Voice funktionieren nur richtig, wenn die Kapazität ausreicht und sich Verzögerungen, Jitter und Paketverluste in Grenzen halten.Dies ist über das 2,4‑GHz-Band kaum umsetzbar.

Hinweise zum Entwerfen und zur Bereitstellung

Wenn Sie eine WLAN-Architektur für Echtzeitanwendungen entwerfen, sollte die Kapazität eine größere Rolle spielen als die Reichweite.

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

Wenn die SSID eines WLANs sowohl auf dem 2,4-GHz- als auch auf dem 5-GHz-Band verfügbar ist, sollte für das Netzwerk eine striktere Steuerung der Frequenzbänder implementiert werden, um Clients zur Nutzung des 5-GHz-Bandes zu zwingen.

• An einem ZP sollten nicht mehr als 10 Tischtelefone angeschlossen sein. Bei einer größeren Anzahl kann es zu unvorhersehbaren Störungen kommen.
• Drahtlos verbundene Tischtelefone sollten nicht von Teams verwendet werden, die viel telefonieren, z. B. vom Kundenservice oder von Supportteams. Dazu zählen auch GOVO-Websites und rund um die Uhr besetzte Callcenter.
• Bei drahtlos verbundenen Festnetztelefonen sind kurze Audioaussetzer von weniger als 10 Sekunden normal und können nicht auf Netzwerkebene beseitigt werden. Wir raten davon ab, wichtige Anrufe wie Konferenzen, Pressetermine oder Gespräche mit Führungskräften über das WLAN zu führen.
• 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 Zugriffspunkten und eine korrekte HF-Verwaltung möglich sind, sollte ein WLAN nicht aus mehreren isolierten eigenständigen Zugriffspunkten bestehen, sondern zentral verwaltet und betrieben werden.

Überprüfen Sie 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:

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

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