Page History

The results cannot show more than 20 hops. 

Where to see this? In the email you will see the following section. Click on the link:

After clicking on it, you will be routed to a page where you have to look for the below section and there you will see the amount of hops, in this case this is not an issue because the total amount is 14.



What to do if the # of hops is greater than 20 hops? Don't escalate the case, just recommend the client to check with their ISP why the routing is taking this amount of hops. If the client continues pushing back, escalate and make sure you highlight this result.

1. The result cannot show more than 200ms of RTT (Average)
   

   Note
   title Additional note about the RTT
   This average could be bigger if the agents are in locations such as India or Phillipines. The maximum here could be 300ms.

   
   

2. The result cannot have more than 20 ms of Jitter.
3. The result cannot have less than 3.0 MOS score → Min value: 0 (worst) - Max value: 4.2 (best)
4. The result cannot have 3-4% packet loss on the upstream or downstream since this could cause audio quality issues.
   
   Where to see this? In the email you will see the following section. You can click on the link of see this specific item in the email:
   
   
   
   If you click on the link, the information will be available in the next section:
   
   
   
   

   What to do if one or more of the above results appear? Don't escalate the case, just recommend the client to check with their ISP. If the client continues pushing back, escalate and make sure you highlight this result. 
   
   

If some logical port is blocked the test will show it (TCP 80, TCP 443, TCP 8080, UDP 5060, TCP 5061, TCP 5071, UDP 15001-15005, UDP 20001-20005 and UDP 29991-29995).

However, it is important to remark that the port may be or not the cause of the issue depending on the implementation that the client has (how they establish the audio path):

• TCP 443 → Used for Web traffic (HTTPS)

• TCP 8080 → Used for WebRTC traffic (web and audio paths established simultaneously)

• UDP 5060 → Used for SIP-Trunks when the client's PBX does not support encryption with TLS version 1.2
• TCP 5061 → Used for SIP-Trunks when the client's PBX supports encryption with TLS version 1.2. Also used for sLVC (99.9% of the clients use the Secured accounts). If a client just says LVC, probably they are referring to sLVC since currently 99% of our clients are using this type of configuration.
• TCP 5071 → Used for sLVT (hard-phones supported: Polycom VVX-310 and SoundPoint-331)
• UDP 15000-30000 → Used for RTP streams (audio)

How to understand the above? If a client is establishing the audio path via WebRTC and the result shows that the port TCP 5061 is blocked but the TCP 8080 is enabled, then, this is not the cause of the issue.