David

Hi all.  As noted in the documentation there are instances where gaps or spaces may occur from the html.
Where can I use Markdown and HTML in Zendesk Support



So, if you “minify” your code this should work. Minifying basically means is you just squish it all together in one long string. 
So in the example from this posting, it would look like this instead:  (this should remove any line breaks)

Question

J’ai suivi les instructions de cet article et j’ai effectué le test réseau Twilio. Cependant, je ne sais pas vraiment comment lire les résultats. Comment utiliser le test réseau Twilio pour dépanner les appels des agents Zendesk Talk ?

Réponse

La plupart des problèmes Talk ou du centre d’appels VoIP proviennent de la vitesse de la connexion réseau, ainsi que de la stabilité et de la qualité de celle-ci. Une connexion rapide ne suffit pas pour une communication vocale en temps réel. Les paquets abandonnés ou une connexion instable peuvent causer des problèmes.

Effectuez le test réseau Twilio pour comprendre si votre connexion fonctionne. Ce test permet de s’assurer que vous suivez les exigences, comme un réseau approprié, que vos ports sont ouverts, que votre navigateur prend en charge les appels et que votre micro et vos haut-parleurs fonctionnent.

Les tests réseau Twilio sont divisés en deux colonnes :

• Diagnostic WebRTC Twilio
• Sortie de journal

Diagnostic WebRTC Twilio

Pour tous les tests ci-dessus, vous devez voir le message vert de réussite. Un message d’échec rouge peut indiquer des problèmes de réseau, en particulier si vous recevez des erreurs avec UDP, TLS ou TCP.

• Si votre agent travaille dans un environnement de bureau, ces erreurs peuvent se produire en raison d’un blocage. Vérifiez que votre équipe réseau a respecté la configuration réseau requise pour Talk et a ouvert les ports, ainsi que les adresses IP et les domaines en liste blanche.
• S’il s’agit d’un réseau domestique pour l’agent, vérifiez l’absence de configuration spéciale ou de routeur domestique qui bloque les ports. Un examen plus approfondi de son réseau peut s’avérer nécessaire.

Sortie de journal

La colonne de droite du test réseau Twilio contient la sortie du journal.

La capture d’écran ci-dessus fait référence aux éléments ci-dessous :

• Vérifiez que les journaux ci-dessous s’affichent en vert. Le rouge indique un problème.
  • A) Connexion UDP à Twilio établie en ___ ms
  • B) Connexion TCP à Twilio établie en ___ ms
  • C) Connexion TLS à Twilio établie en ___ ms
• D) Assurez-vous que même si vous réussissez le test de bande passante, les résultats sont bien plus élevés que dans l’exemple ci-dessus. Dans celui-ci, les résultats représentent le seuil le plus bas pour un fonctionnement fiable de Talk.
  Remarque : les nombres testés représentent le seuil le plus bas pour Talk.
• E) Vérifiez le client Twilio connecté à, effectuez le contrôle et assurez-vous que vous êtes connecté au bon point de terminaison. Il est possible qu’un réseau privé virtuel (VPN) vous connecte au mauvais point de terminaison, par exemple, si vous êtes en Allemagne, mais que le journal montre que vous êtes connecté à un point de terminaison américain. La connexion au mauvais point de terminaison entraîne une latence. Twilio doit décider de la meilleure route à suivre, mais un VPN peut masquer la région ou l’emplacement réel d’un agent. La région peut avoir l’une des valeurs suivantes : au1, br1, de1, ie1, jp1, sg1, us1. Pour les dernières informations au sujet des régions de Twilio, consultez l’article de Twilio : Régions héritées.
• F) RTT (Round Trip Time ou Temps aller-retour) : idéalement, le temps RTT doit être inférieur ou égal à 150 ms. Plus la valeur RTT est élevée, plus l’appel risque d’être de mauvaise qualité.
• G) Gigue : l’audit de la gigue ne doit pas dépasser 20 ms. Une gigue élevée peut entraîner des retards.
• H) Perte de paquets : une perte de paquets indique une connexion instable, et même une perte de 1 % peut être à l’origine de problèmes.

Hey all.  Just want to clarify the screenshot above  is not meant to be used as an exact benchmark.  I would say this is an ideal setup above.  If you run this test where it "passes" this is not necessarily indicative of what one would call a quality connection. For example at a minimum I would say for the above, you would want your "lowest" amounts for the above "Simultaneous connections" should be at least 10 or more.  Packet loss should be 0, jitter should be low, etc. If your getting packet loss, jitter and your lowest amount of simultaneous connections is 2, you may pass this test barely but your calls are likely to have a lot of problems.   

the graphic is just an illustration of what the test looks like and what to be aware of during the test.  As Jeff mentions above getting better results on your network connection has a wide variety of factors.  The best place to start is with our Talk troubleshooting guide below which has many suggestions like changing to a hard wired connection like Jeff mentioned or running network tests and working with your network admin.

https://support.zendesk.com/hc/en-us/articles/203661086-How-can-I-troubleshoot-Talk-issues- 

It's my opinion the majority of problems we see are related to VPN or VDI implementations.  Make sure you follow the advice in the networking requirements regarding VPN's.  I.E. make sure to exclude traffic for Twilio and Zendesk ips and domains:

In scenarios where using a proxy, MPLS, or VPN is unavoidable, it's crucial to exclude traffic intended for Zendesk and Twilio domains, including your FQDN subdomain.zendesk.com, and the specified IP addresses outlined in the accompanying documentation. This exclusion is critical to ensure the proper functionality of Talk within these network configurations.