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)

질문

이 문서의 안내에 따라 Twilio 네트워크 테스트를 수행하였습니다. 하지만 결과를 어떻게 읽는지 잘 모르겠습니다. Twilio 네트워크 테스트를 사용하여 Zendesk Talk 상담사 통화 문제를 해결하려면 어떻게 해야 하나요?

답변

대부분의 Talk 또는 VoIP(Voice over Internet Protocol) 문제는 네트워크 연결의 속도는 물론 네트워크 연결의 안정성과 품질에서 비롯됩니다. 빠른 연결만으로는 실시간 음성 커뮤니케이션을 할 수 없습니다. 패킷이 끊기거나 연결이 불안정해도 문제가 발생할 수 있습니다.

Twilio 네트워크 테스트를 수행하여 연결이 제대로 작동하는지 확인하세요. 이 테스트를 통해 적절한 네트워크, 포트가 열려 있는지, 브라우저가 통화를 지원하는지, 마이크와 스피커가 작동하는지 등의 요구 사항을 준수하는지 확인합니다.

Twilio 네트워크 테스트는 다음 두 개의 컬럼으로 나눌 수 있습니다.

• Twilio WebRTC 진단
• 로그 출력

Twilio WebRTC 진단

위의 모든 테스트에 대해 녹색 통과 메시지가 표시되어야 합니다. 빨간색 실패 메시지는 특히 UDP, TLS 또는 TCP에서 오류가 발생하는 경우 네트워크 문제를 나타낼 수 있습니다.

• 상담사가 사무실 환경에서 작업하는 경우에는 무언가가 차단되어 그러한 오류가 발생할 수 있습니다. 네트워크 팀이 Talk 네트워크 요구 사항을 따르고 포트를 열고 IP 주소 및 도메인을 허용 목록에 추가했는지 확인하세요.
• 상담사의 홈 네트워크인 경우에는 상담사에게 특별한 설정이나 홈 라우터 차단 포트가 없는지 확인하세요. 상담사의 네트워크에 대한 추가 조사가 필요할 수 있습니다.

로그 출력

Twilio 네트워크 테스트의 오른쪽 컬럼에는 로그 출력이 포함됩니다.

위의 스크린샷은 아래 요소를 나타냅니다.

• 아래 로그가 녹색으로 표시되는지 확인합니다. 빨간색은 문제가 있음을 나타냅니다.
  • A) ___ms 후에 Twilio에 대한 UDP 연결을 성공적으로 설정했습니다.
  • B) ___ms 후에 Twilio에 대한 TCP 연결을 성공적으로 설정했습니다.
  • C) ___ms 후에 Twilio에 대한 TLS 연결을 성공적으로 설정했습니다.
• D) 대역폭 테스트를 성공적으로 통과했더라도 결과가 위의 예보다 훨씬 더 높은지 확인합니다. 거기서 결과는 Talk가 안정적으로 작동하는 최저 임계값을 나타냅니다.
  참고: 테스트의 숫자는 Talk의 최저 임계값입니다.
• E) 감사에 연결된 Twilio 클라이언트를 확인하고 올바른 엔드포인트에 연결되어 있는지 확인합니다. VPN(가상사설망)을 사용하면 잘못된 엔드포인트에 연결될 수 있습니다. 예를 들어, 사용자가 독일에 있지만 로그에는 미국 엔드포인트에 연결된 것으로 표시되는 경우가 있습니다. 잘못된 엔드포인트에 연결하면 지연 시간이 발생합니다. Twilio가 가장 적합한 경로를 결정해야 하지만 VPN에서 상담사의 실제 위치나 지역을 숨길 수 있습니다. 지역은 au1, br1, de1, ie1, jp1, sg1, us1 중 하나일 수 있습니다. Twilio의 지역에 대한 최신 정보는 Twilio 문서인 Legacy Regions를 참조하세요.
• F) RTT(왕복 시간): RTT는 150ms 이하여야 합니다. RTT 값이 높을수록 통화 품질이 떨어질 가능성이 높습니다.
• G) 지터: 지터 감사는 20ms를 초과할 수 없습니다. 높은 지터로 인해 지연이 발생할 수 있습니다.
• H) 패킷 손실: 패킷 손실은 불안정한 연결을 나타내며 1%의 패킷 손실도 문제를 일으킬 수 있습니다.

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.