Netzwerkanforderungen für Talk

Suite all alle Pläne

Zendesk Talk nutzt das Internet für ab- und eingehende Telefonanrufe. Deshalb ist ein schnelles und zuverlässiges Netzwerk unverzichtbar. Am besten eignet sich ein kabelgebundenes Netzwerk mit WLAN, doch gleich welches Netzwerk Sie verwenden, Sie müssen es wahrscheinlich für den Betrieb mit Talk konfigurieren. Wenn Sie die erforderlichen Änderungen nicht selbst vornehmen können, sprechen Sie mit Ihrer IT-Abteilung. Die richtige Konfiguration hilft, folgende Werte zu reduzieren:

Latenz: Die Zeit, die die RTP-Medienpakete benötigen, um zu ihrem Zielort zu gelangen. Eine hohe Latenz kann die Medienübertragung verzögern und Telefongespräche stören.
Paketverlust: Pakete, die nicht am Zielort ankommen. Paketverluste können Lücken und Sprünge in Medien verursachen und dazu führen, dass die Gesprächspartner sich nicht hören.
Jitter: Pakete, die nicht in der richtigen Reihenfolge am Zielort ankommen. Jitter verursacht „roboterartige“ Verzerrungen in Medien und Paketverluste beim Überlauf des Jitterpuffers.

Anhand der Informationen in diesem Beitrag können Sie Netzwerkprobleme minimieren und Talk optimal nutzen. Allgemeine Informationen zu den Vorbereitungen für die Verwendung von Talk finden Sie unter Optimieren der Anrufqualität in Zendesk Talk.

Hinweis: Talk funktioniert nicht mit MPLS oder VPN. Der Grund hierfür ist ein Dienst namens GLL, der im Hintergrund ausgeführt wird. Dieser Dienst bestimmt den für den Anruf am besten geeigneten Netzwerkpfad. Wenn Sie ein VPN oder MPLS verwenden, kann GLL den tatsächlichen Standort Ihrer Agenten nicht ermitteln und deshalb den Anruf nicht effizient routen, was zu Latenzen und anderen Problemen mit der Anrufqualität führen kann. Wenn Sie ein VPN verwenden müssen, sorgen Sie dafür, dass der Datenverkehr für die Zendesk-/Twilio-Domänen (einschließlich Ihrer subdomäne.zendesk.com) und die in diesem Beitrag aufgeführten IP-Adressen nicht über VPN geroutet wird.

In diesem Beitrag werden folgende Themen behandelt:

Von Talk benötigte Ports, Domänen und IP-Adressen
Verwenden von DSCP
Weitere Fehlerbehebung

Von Talk benötigte Ports, Domänen und IP-Adressen

Möglicherweise müssen Sie Ihr Netzwerk anpassen, damit Talk richtig funktioniert. Die Änderungen müssen auf allen Firewalls, Routern, Switches, Load-Balancern und sonstigen Hardware- oder Softwarekomponenten zugelassen werden, die den Talk-Netzwerkverkehr blockieren oder manipulieren könnten.

Ports

Talk verwendet die folgenden Ports (abgehend):

TCP: 80, 443
UDP: 10.000 bis 20.000

Die oben genannten Ports müssen mit allen folgenden Domänen und IP-Adressen kommunizieren können.

Zendesk wird von Amazon Web Services (AWS) gehostet. Eine Liste aller AWS-spezifischen IP-Bereiche, die Sie zulassen müssen, finden Sie unter Konfigurieren der Firewall zur Verwendung von Zendesk.

Lassen Sie außerdem Ihre Zendesk-Subdomäne in Ihrem Netzwerk zu: *.{{ihresubdomäne}}.zendesk.com .

Twilio-Domänen

Twilio ist der Telefonanbieter für Zendesk Talk. Die folgende Liste enthält die Twilio-Domänen, auf die der Zugriff möglich sein muss.

chunderw-gll.twilio.com

chunderw-vpc-gll.twilio.com

chunderw-vpc-gll-au1.twilio.com

chunderw-vpc-gll-br1.twilio.com

chunderw-vpc-gll-ie1.twilio.com

chunderw-vpc-gll-jp1.twilio.com

chunderw-vpc-gll-sg1.twilio.com

chunderw-vpc-gll-us1.twilio.com

matrix.twilio.com

eventgw.twilio.com

chunderw-vpc-gll-de1.twilio.com

Twilio IP-Adressen

Die folgende Liste enthält die Twilio-Domänen, auf die der Zugriff möglich sein muss.

Wichtig: Wir bemühen uns, unsere Kunden zu kontaktieren und über neue Einträge in dieser Liste zu informieren. Dennoch sollten Sie sich vergewissern, dass Ihr Netzwerkteam sie zu den vorhandenen Firewall-, Load-Balancer- und sonstigen Netzwerkgeräteregeln hinzugefügt hat.

54.252.254.64/26

177.71.206.192/26

54.171.127.192/26

52.215.127.0/24

54.65.63.192/26

54.169.127.128/26

54.172.60.0/23

34.203.250.0/23

35.156.191.128/25

Kürzlich hinzugefügt

54.244.51.0/24

3.1.77.0/24

3.112.80.0/24

3.122.181.0/24

18.228.249.0/24

3.104.90.0/24

Weitere Überlegungen

Darüber hinaus müssen folgende Netzwerkkonfigurationen eingerichtet werden:

Sorgen Sie dafür, dass die IP-Adressen und Domänen sowohl von Zendesk als auch von Twilio von der SPI-Prüfung (Stateful Packet Inspection) ausgenommen sind. Andernfalls können hohe UDP- oder TCP-Verbindungszeiten auftreten.
In manchen Fällen können beim Anschluss eines Switch oder eines anderen Netzwerkgeräts an einen nicht korrekt konfigurierten Cisco Smart Switch die zugelassenen Domänen und IP-Adressen blockiert werden. Um das zu vermeiden, sollten Sie keine Hardware mit einem Smart Switch verbinden, die nicht dafür vorgesehen ist, und sich bei Ihrem Netzwerkteam vergewissern, dass die oben aufgeführten Einstellungen konfiguriert sind.
Ihre Firewall muss sowohl abgehende UDP-Verbindungen der für Talk verwendeten Browser in das öffentliche Internet als auch Antworten darauf zulassen. Zendesk wird auf AWS gehostet. Deswegen ist es nicht möglich, den IP-Bereich einzugrenzen. Aufgrund der AWS-Netzwerkverbindung liegen manche IP-Adressen möglicherweise etwas außerhalb dieser Bereiche.
Wenn Ihr Router über SIP Application Level Gateway (ALG) oder Stateful Packet Inspection (SPI) verfügt, deaktivieren Sie diese beiden Funktionen für Netzwerke, in denen Sie Zendesk Talk nutzen.
Talk funktioniert nicht mit MPLS oder VPN. Lassen Sie den Datenverkehr für die aufgeführten Domänen und IP-Adressen nicht über ein VPN laufen.

Wenn Sie Verbindungen zu allen oben genannten IP-Adressen und Domänen über die oben genannten Ports zugelassen haben (alle Ports müssen auf alle genannten Domänen und IP-Adressen zugreifen können), sollten keine Probleme mit abgehenden und eingehenden Zendesk Talk-Anrufen auftreten.

Verwenden von DSCP

DSCP-Tags in Paketen teilen den Netzwerkkomponenten mit, wie der Datenverkehr priorisiert werden soll. Standardmäßig weisen Talk-Anrufe ein DSCP-Tag mit dem Wert 46 auf. Wenn Ihr Netzwerk überlastet ist, sollten Sie DSCP wie in diesem Beitrag beschrieben implementieren. Der Twilio Client 1.3 (und höher) aktiviert DSCP standardmäßig in kompatiblen Browsern (z. B. Google Chrome).

Kompatible Browser markieren WebRTC-Medienpakete. Dadurch können Datenpakete im LAN differenziert verarbeitet und Echtzeitmedien gegenüber dem übrigen Netzwerkverkehr priorisiert werden. Das Feld „Differentiated Services“ befindet sich beim IPv4-Header im Oktett „TOS“ bzw. beim IPv6-Header im Oktett „Traffic Class“. Ein Differentiated-Services-konformer Netzwerkknoten (z. B. ein Router) enthält einen Klassifizierer, der Pakete anhand des DS-Feldwertes auswählt und gemeinsam mit Pufferverwaltungs- und Paketplanungsmechanismen dafür sorgt, dass sie entsprechend weitergeleitet werden.

Mit Twilio Client 1.3 gesendete RTP-Pakete weisen in den lokalen Wireshark-Paketcaptures einen DiffServ-Codepunkt auf. Wenn Sie DSCP aktivieren, markiert die WebRTC-Engine die RTP-Pakete mit EF. Die Werte für die beschleunigte Weiterleitung lauten wie folgt:

binär: 101 110
hexadezimal: 0x2e
dezimal: 46

Sie müssen einen Browser verwenden, der webRTC unterstützt (z. B. Chrome oder Firefox). Wenn Sie DSCP implementieren (empfohlen), verwenden Sie die neueste (nicht-Beta) Version von Chrome, da dieser als einziger Browser DSCP unterstützt.

Sie können prüfen, ob Sie über die neueste Version von Chrome verfügen, indem Sie „chrome://help/“ in der Adressleiste eingeben. Wenn die Schaltfläche Neu starten angezeigt wird, klicken Sie sie an, um Chrome zu aktualisieren.

Prüfen der Funktion von DSCP

In manchen Windows-Umgebungen werden DSCP-Tags herausgefiltert, obwohl das Netzwerk für DSCP eingerichtet ist. Ihr Netzwerkteam kann dies anhand einer Wireshark-Capture überprüfen. Erzwingen Sie DSCP entweder mit einer entsprechenden Gruppenrichtlinie oder – wenn Ihre Computer nicht einer Domäne angehören – implementieren Sie die Richtlinie für die einzelnen Computer.

Um sicherzustellen, dass Windows die DSCP-Tags nicht entfernt, müssen Sie die unten beschriebenen Schritte ausführen. Die genaue Vorgehensweise hängt davon ab, ob Ihr Computer einer Domäne angehört oder nicht.

Überprüfen von DSCP-Tags bei Computern, die nicht einer Domäne angehören

In diesem Abschnitt bearbeiten Sie die Windows-Registrierung so, dass Sie die QoS-Einstellung festlegen können, die ausgehend von einer von Ihnen konfigurierten Gruppenrichtlinie verwendet werden soll.

So überprüfen Sie DSCP-Tags bei einem Computer, der keiner Domäne angehört

Navigieren Sie im Windows-Registrierungs-Editor zu HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services > Tcpip > QoS. Wenn der Schlüssel „QoS“ nicht existiert, klicken Sie mit der rechten Maustaste auf Tcpip, wählen Sie Neuer Schlüssel und geben Sie QoS ein.
Klicken Sie auf den Schlüssel QoS.
Wenn der String noch nicht vorhanden ist, erstellen Sie einen neuen String-Wert namens Do not use NLA.
Setzen Sie den Wert auf 1.
Ihr Fenster sieht nun folgendermaßen aus:
Starten Sie den Computer neu, um die Einstellungen zu übernehmen.

Überprüfen von DSCP-Tags bei Computern, die einer Domäne angehören

Bei Computern, die einer Domäne angehören, werden die QoS-Einstellungen mithilfe von Gruppenrichtlinienregeln gesteuert.

So überprüfen Sie DSCP-Tags bei Computern, die einer Domäne angehören

Geben Sie im Windows-Befehlszeilenfenster„gpedit.msc“ ein, um den Windows-Gruppenrichtlinen-Editor aufzurufen.
Erweitern Sie unter Computerkonfiguration die Windows-Einstellungen.
Klicken Sie mit der rechten Maustaste auf Richtlinienbasierter QoS und dann auf Neue Richtlinie erstellen.
Ein Assistent für die Konfiguration der zu verwendenden QoS-Regeln wird geöffnet.
Geben Sie auf ersten Bildschirm als Richtliniennamen „Zendesk Talk DSCP“ und als DSCP-Wert „46“ ein.
Klicken Sie auf Weiter.
Beschränken Sie die Liste im zweiten Bildschirm auf ausführbare Dateien und geben Sie Chrome.exe ein.
Klicken Sie auf Weiter.
Klicken Sie auf dem dritten Bildschirm auf Weiter.
Wählen Sie auf dem letzten Bildschirm das Protokoll aus, für das QoS gilt. Für Zendesk Talk ist das nur UDP.
Außerdem können Sie auf dieser Seite verschiedene Portbereiche auswählen. Nehmen Sie hier vorerst keine Änderungen vor.

Wenn Sie fertig sind, sieht Ihre Regel ungefähr so aus:

Mit diesen Schritten sorgen Sie dafür, dass WebRTC-Pakete priorisiert werden und Zendesk Talk optimal funktioniert.

Die neue Gruppenrichtlinie tritt erst nach einem Neustart der Client-Computer in Kraft.

Referenzen:

Anforderungen für Windows-Computer

Auf Computern mit Windows-Betriebssystem können Probleme mit Zendesk Talk auftreten. Zendesk Talk-Kunden müssen den Starttyp des Dienstes „Quality Windows Audio Visual Experience“ von „Manuell“ (Standardeinstellung) in „Automatisch“ ändern.

So aktivieren und starten Sie QWAVE automatisch

Geben Sie im Windows-Startmenü „cmd“ ein.
Klicken Sie mit der rechten Maustaste auf das Symbol Eingabeaufforderung und klicken Sie dann auf Als Administrator ausführen.
Fügen Sie den folgenden Text in die Befehlszeile ein:
```
net start QWAVE 
```
Drücken Sie die Eingabetaste. Der folgende Bildschirm wird angezeigt.
Fügen Sie den folgenden Text ein, um den Starttyp des Dienstes auf „Automatisch“ einzustellen:
```
REG add "HKLM\SYSTEM\CurrentControlSet\services\QWAVE" /v Start /t REG_DWORD /d 2 /f
```
Drücken Sie die Eingabetaste.

Der Starttyp des „QWAVE“-Dienstes ist jetzt auf „Automatisch“ eingestellt. Falls bei den oben beschriebenen Schritten ein Fehler auftritt, bitten Sie ein Mitglied Ihres IT-Teams oder einen Computeradministrator, die Schritte für Sie auszuführen. Richten Sie in Ihrem Netzwerk eine Gruppenrichtlinie ein, damit der Dienst auf allen Client-Computern auf „Automatisch“ eingestellt wird.

Weitere Fehlerbehebung

Zusätzlich zu den oben beschriebenen Schritten können Sie auch das Twilio SDK verwenden, um die Qualität Ihrer Anrufe zu untersuchen. Weitere Informationen finden Sie in der Voice Insights SDK Events Reference (Englisch).