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: max. 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 Voicetraffic in der Proxykonfiguration auf die Zulassungsliste.
• Voice greift nicht wie Google Meet auf TCP zurück. Voice verwendet UDP nur für Voicetraffic.
• 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 Google-Backend 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 reduziert.

Die Paketprüfung von Audio-Traffic bietet ebenfalls wenig Nutzen, da automatisierte Scan-Tools keine Audio-Stream-Daten 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.

Die Ausführung von Echtzeitanwendungen über ein drahtloses Netzwerk kann eine Herausforderung sein, da das zugrunde liegende HF-Spektrum und die Bandbreite von allen Geräten, die es verwenden, gemeinsam genutzt 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 (normalerweise stark ausgelastete) 2,4‑GHz-Band eines WLANs bereitzustellen und zu betreiben. Diese Empfehlung umfasst Anwendungen, die in einer normalen Büroumgebung Konnektivität bieten.

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, die über das 2, 4‑GHz-Band kaum zu erreichen sind.

Hinweise zu Design und Bereitstellung

Wenn Sie ein WLAN 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 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 ZP zu übertragen.

Wenn die SSID eines WLANs sowohl auf dem 2,4‑GHz- als auch auf dem 5‑GHz-Band verfügbar ist, sollte erzwungen werden, dass Clients im Netzwerk das 5‑GHz-Band nutzen.

• Eine realistische Erwartung ist, dass nicht mehr als 10 VoIP-Telefone 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 Anrufvolumen verwendet werden, z. B. von Kundenservicemitarbeitern oder Supportteams. Beispiele 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 behoben werden. Wir empfehlen, für wichtige Telefonanrufe wie Konferenzen, Pressegespräche oder Anrufe von Führungskräften keine WLANs 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.