Zendesk Talk utilise Internet pour passer et recevoir des appels. Il est donc important d’avoir un réseau rapide et fiable. Un réseau câblé avec le wifi désactivé est l’idéal mais, quel que soit le type de réseau que vous choisissez d’utiliser, vous devrez probablement le configurer pour qu’il fonctionne correctement avec Talk. Si vous ne savez pas le faire, demandez de l’aide à votre service informatique. Ces configurations peuvent permettre de réduire :
- Latence : le temps nécessaire pour que les paquets RTP (média) arrivent à destination. La latence peut provoquer des retards de livraison des médias et les voix des participants à l’appel risquent de s’entrecouper. Plus la latence est faible, plus votre appel donnera l’impression qu’il n’y a que deux personnes qui parlent dans la même pièce. Quand la latence augmente, il se produit le contraire et votre appel risque d’être interrompu ou haché, ce qui peut faire que les participants parlent en même temps.
- Gigue/sautillement : l’évolution de la latence dans le temps. Cela donne souvent l’impression qu’il y a des interférences ou que quelqu’un essaie de brancher son micro sans y parvenir. En outre, les appelants risquent de ne pas s’entendre.
- Perte de paquets : quand les signaux vocaux sont numérisés et transmis, ils sont divisés en paquets. Si certains de ces paquets n’arrivent jamais à leur destination, des petits morceaux du signal audio manquent, ce qui provoque une distorsion audible de l’appel.
Utilisez les informations contenues dans cet article pour minimiser les problèmes de réseau et tirer le meilleur parti de Talk. Pour des informations générales sur la prise en main de Talk, consultez Préparation à l’utilisation de Zendesk Talk. Pour éviter les problèmes de réseau, tout devrait être câblé : un casque avec prise de 3,5 mm câblé et une connexion Internet filaire (désactiver le wifi).
Certaines applications utilisent beaucoup de bande passante, surtout les applications de streaming de fichiers. Zendesk Talk nécessite 500 kbit/s par agent qui utilise Talk (cela prend en compte l’exécution simultanée de Talk et Zendesk Support). Si vous avez 50 agents, vous avez besoin d’une ligne dédiée de 500 kbit/s (QoS) pour chacun d’entre eux, c’est-à-dire une ligne de 50 Mbit/s minimum.
Quand vous essayez de résoudre des problèmes de réseau, essayez de fermer les applications comme Netflix, Spotify, YouTube, etc.
Cet article aborde les sujets suivants :
Ports, domaines et adresses IP requis par Talk
Pour que Talk fonctionne, vous devrez peut-être ajuster la configuration de votre réseau. Toutes les modifications doivent être autorisées pour tous les pare-feux, routeurs, commutateurs, équilibreurs de charge et tout autre matériel ou logiciel pouvant bloquer ou manipuler le trafic réseau Talk.
Ports
Vérifiez que les ports du tableau ci-dessous peuvent communiquer avec tous les domaines et adresses IP couverts dans cet article.
Zendesk est hébergé par Amazon Web Services (AWS). Pour voir la liste de toutes les plages IP d’AWS que vous devez autoriser, consultez Configuration de votre pare-feu pour l’utiliser avec Zendesk.
Vous devez autoriser votre sous-domaine Zendesk sur votre réseau, par exemple :
*.{{votre_sousdomaine}}.zendesk.com
Talk utilise les ports suivants (sortants) :
| TCP / UDP : | 443,3478 |
| UDP | 10 000 à 60 000 | 443 | 3478 |
| TCP | 5349 |
Domaines Twilio
Twilio est le fournisseur du Centre d’appels pour Zendesk Talk. Cette liste répertorie les domaines Twilio auxquels vous devez autoriser l’accès.
| 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 |
| gwasset.twilio.com |
| sdk.twilio.com |
Adresses IP Twilio
Cette liste répertorie les domaines Twilio auxquels vous devez autoriser l’accès.
| 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 |
Ajouts récents
| 54.244.51.0/24 | 44.234.69.0/25 |
| 3.1.77.0/24 | 3.235.111.128/25 |
| 3.112.80.0/24 | 18.141.157.128/25 |
| 3.122.181.0/24 | 18.180.220.128/25 |
| 18.228.249.0/24 | 3.249.63.128/25 |
| 3.104.90.0/24 | 3.7.35.128/25 |
| 72.52.10.0/24 | 18.230.125.0/25 |
| 65.9.130.0/24 | 3.25.42.128/25 |
https://pubsub-shard2-17-1.zendesk.com
https://pubsub-shard2-17-2.zendesk.com
https://pubsub-shard2-17-3.zendesk.com
https://pubsub-shard2-17-4.zendesk.com
Autres considérations
Vous devez effectuer les configurations réseau supplémentaires suivantes :
- Vérifiez que les adresses IP et domaines Zendesk et Twilio sont exclus de la vérification SPI pour éviter des temps de connexion UDP ou TCP.
- Dans certains cas, les clients ont signalé que si un commutateur ou autre matériel réseau est branché à un commutateur intelligent Cisco mal configuré, il peut outrepasser tous les domaines et adresses IP. Pour empêcher que cela ne se produise, ne branchez pas de matériel qui n’est pas conçu pour être branché à un commutateur intelligent et demandez à votre équipe réseau de vérifier qu’il est configuré pour refléter les paramètres ci-dessus.
- Votre pare-feu doit autoriser UDP sortant vers l’Internet public à partir des navigateurs qui utiliseront Talk, ainsi que le trafic entrant en réponse. Zendesk étant hébergé sur AWS, il n’est pas possible de rétrécir les plages IP. Vous verrez peut-être des adresses IP hors de ces plages à cause des réseaux AWS.
- Si votre routeur inclut la fonction SIP Application Level Gateway (ALG) ou Stateful Packet Inspection (SPI), désactivez-les sur les réseaux qui utilisent Zendesk Talk.
- Talk ne fonctionne ni avec MPLS ni avec VPN. N’autorisez pas le trafic pour les adresses IP et domaines répertoriés à passer par un VPN.
Après avoir autorisé les connexions à tous les domaines et adresses IP ci-dessus pour les ports mentionnés (chaque port doit pouvoir accéder à l’ensemble des adresses IP et domaines répertoriés), Zendesk Talk devrait pouvoir passer et recevoir des appels.
Utilisation de Talk avec un proxy, MPLS ou VPN
Talk ne fonctionne pas avec une configuration proxy, MPLS ou VPN à cause du service GLL qui s’exécute en arrière-plan. Ce service choisit le meilleur chemin réseau pour l’appel. Si vous utilisez un proxy, MPLS ou VPN, il ne donne pas l’emplacement véritable de vos agents et Talk ne peut donc pas router l’appel efficacement, ce qui peut déboucher sur des problèmes de latence et autres problèmes de qualité des appels. Si vous êtes obligé d’utiliser un proxy, MPLS ou VPN, n’autorisez pas le trafic pour vos domaines Zendesk et/ou Twilio (y compris votre sous_domaine.zendesk.com FQDN) et utilisez les adresses IP répertoriées dans cet article pour passer par votre VPN.
Zendesk Talk n’est pas compatible avec les environnements de bureau virtuels.
Utilisation de DSCP
Pour en savoir plus sur les directives d’implémentation de DSCP, consultez Configuration des paramètres QoS (Qualité de service) pour Talk sur les domaines Windows.
Les marqueurs DSCP dans les paquets sont utiles pour indiquer aux appareils réseau comment prioriser le trafic. Par défaut, les appels Talk ont un marqueur DSCP de 46. Si vous rencontrez des problèmes d’encombrement sur votre réseau, envisagez d’implémenter DSCP en suivant les instructions de cet article. Le client Twilio version 1.3 et supérieure active DSCP par défaut dans les navigateurs compatibles, comme Google Chrome.
Les navigateurs compatibles marquent les paquets média WebRTC. Cela permet un traitement différencié sur un réseau local (LAN) afin de donner la priorité aux médias en temps réel par rapport au reste du trafic réseau. Le champ de services différenciés (DS) se trouve dans l’octet TOS de l’en-tête IPv4 ou dans l’octet de classe de trafic IPv6. Un nœud de réseau conforme aux services différenciés (p. ex., un routeur) inclut un classificateur qui sélectionne les paquets en fonction de la valeur du champ DS, ainsi que les mécanismes de gestion de la mémoire tampon et de programmation des paquets capables de fournir le transfert des paquets spécifique indiqué par la valeur du champ DS.
Avec le client Twilio version 1.3, les paquets RTP envoyés auront un DSCP dans les captures de paquets Wireshark locales. Quand vous activez DSCP, le moteur WebRTC marque les paquets RTP avec EF et les valeurs liées au transfert accéléré :
- Binaire : 101 110
- Hexadécimal : 0x2e
- Décimal : 46
Vous devez utiliser un navigateur qui prend webRTC en charge, par exemple Chrome ou Firefox. Si vous implémentez DSCP (conseillé), utilisez Chrome (la dernière version non bêta) car c’est le seul navigateur qui le prend en charge.
Pou vérifier que vous utilisez la dernière version de Chrome, allez à chrome://help/ dans la barre d’adresse de votre navigateur. Si vous voyez un bouton permettant de relancer le navigateur, cliquez dessus pour mettre Chrome à jour.
Vérification correcte des fonctions DSCP
Dans certains environnements Windows, les marqueurs DSCP sont filtrés et exclus même si le réseau est configuré pour DSCP. Votre équipe réseau peut vérifier si c’est le cas en exécutant une capture dans Wireshark. Implémentez une stratégie de groupe qui appliquera DSCP ou, si vos ordinateurs ne font pas partie d’un domaine, implémentez-la individuellement sur chaque ordinateur.
Pour vous assurer que Windows n’exclut pas les marqueurs DSCP, vous devez suivre les étapes ci-dessous (qui varient selon que votre ordinateur fait partie d’un domaine ou non).
Vérification des marqueurs DSCP pour une machine qui fait partie d’un domaine
Pour les machines qui font partie d’un domaine, vous contrôlez les paramètres de qualité de service (QoS) qui sont utilisés pour certaines applications en créant des règles de stratégie de groupe différentes.
Suivez les étapes ci-dessus pour garantir que les paquets WebRTC ont la priorité, pour un fonctionnement optimal du composeur.
Vous devrez forcer les machines clientes à utiliser cette nouvelle stratégie de groupe pour que cela fonctionne. En général, un redémarrage suffit.
Pour vérifier les marqueurs DSCP pour une machine qui fait partie d’un domaine, suivez ces étapes :
- Ouvrez les règles de stratégie de groupe en saisissant « gpedit.msc » dans la ligne de commande.
- Sous Configuration ordinateur, sélectionnez QoS basée sur la stratégie.
- Cliquez avec le bouton droit et sélectionnez Créer une stratégie.
- Une interface d’assistant s’ouvre pour vous permettre de configurer les règles QoS à utiliser.
- Au premier écran, saisissez « Salesloft DSCP » comme nom de stratégie et spécifiez une valeur DSCP de 46.
- Cliquez sur Suivant.
- Au deuxième écran, sélectionnez Seulement les applications avec nom d’exécutable, puis saisissez « Chrome.exe ».
- Cliquez sur Suivant.
- Au troisième écran, vous n’avez aucun paramètre à saisir. Cliquez sur Suivant.
- Au dernier écran, sélectionnez le protocole auquel s’applique la QoS. Pour le composeur Salesloft, ce sera limité à UDP.
Vérification des marqueurs DSCP pour une machine qui ne fait pas partie d’un domaine
Cette section modifie le paramètre de registre pour vous permettre de spécifier le paramètre QoS qui sera utilisé en fonction des paramètres de stratégie de groupe que vous configurez.
Pour vérifier les marqueurs DSCP pour une machine qui ne fait pas partie d’un domaine, suivez ces étapes :
- Allez à HKEY_LOCAL_MACHINE > CurrentControlSet > Services > tcpip > QoS.
- Si la clé QoS n’existe pas, cliquez sur TCP/IP avec le bouton droit, puis sélectionnez New Key.
- Pour le nom, saisissez « QoS ».
- Puis sélectionnez la clé QoS.
- Si la chaîne n’existe pas encore, créez une nouvelle valeur de chaîne appelée Do not use NLA.
- Configurez la valeur sur 1.
- Redémarrez la machine pour que les paramètres entrent en vigueur.
Configuration requise pour les ordinateurs Windows
Il est possible que vous ayez des problèmes avec Zendesk Talk si vous utilisez un ordinateur Windows. Les clients Zendesk Talk doivent utiliser le service d’expérience audiovisuelle Windows de qualité et configurer son démarrage sur Automatique (et non sur Manuel, la valeur par défaut).
Pour vous assurer que QWAVE est activé et que le démarrage est automatique
- Dans le menu de démarrage Windows, « cmd ».
- Cliquez sur l’icône de l’invite de commandes avec le bouton droit, puis cliquez sur Exécuter en tant qu’administrateur.
- Collez le texte suivant dans la ligne de commande :
net start QWAVE
- Appuyez sur Entrée. Vous verrez les résultats suivants.
- Pour garantir un type de démarrage automatique de façon permanente, collez ce qui suit dans l’invite de commandes afin de configurer le type de démarrage du service sur Automatique.
REG add "HKLM\SYSTEM\CurrentControlSet\services\QWAVE" /v Start /t REG_DWORD /d 2 /f
- Appuyez Entrée.
Le type de démarrage du service QWAVE est désormais configuré sur Automatique. Si vous avez rencontré une erreur en suivant les étapes ci-dessus, demandez à un membre de votre service informatique ou un administrateur de le faire pour vous (vous devez exécuter l’invite de commandes en tant qu’administrateur).
Définissez une stratégie de groupe sur votre réseau pour que tous les ordinateurs clients configurent le service sur Automatique. Vous n’aurez pas à configurer chaque ordinateur manuellement et gagnerez du temps.
Dépannage supplémentaire
Après avoir suivi les étapes précédentes, vous pouvez aussi utiliser le SDK Twilio pour passer la qualité de vos appels en revue. Pour en savoir plus, consultez Événements SDK Insights du centre d’appels - Référence.
0 Commentaires
Vous devez vous connecter pour laisser un commentaire.