Before troubleshooting a call quality issue, you will need to understand the basic network of a call. The figure below shows how each entity fits in the overall network.

Step 1. Identify the type of call quality issues being experienced

There are a few different types of call quality issues:

• Delay in the audio
• Static
• Audio sounding far away or underwater

However, the most common call quality issue is audio “cutting in and out” and this cutting in and out is what this guide will be focusing on. You will initially need to get a description of the call quality issues from the customer. Try not to prompt them. Usually, they will end up describing the audio issues as “cutting in and out”, “chopping” or “dropping in and out”.

The cutting in and out of the audio is directly caused by packet loss somewhere along
the network.

Remember that VOIP services with VoIPcloud use the UDP transmission protocol. This means there is no error-correcting for lost packets. This means that lost packets are lost permanently and result in the end users hearing gaps in the audio stream. Hence the “cutting in and out”. Once you have symptoms from the customer indicating this type of call quality issue, you will need to go to Step 2.

Step 2. Identify the leg of the call that is affected

Identifying the leg affected is important because it affects the way we resolve the issue. The main way to do this is to enable inbound and/or outbound call recordings. Be sure to send the call recordings to yourself as well as the customer for review.

When reviewing the call recordings, you may or may not hear the quality issue. This is why it's important that the customer listens to the recording. Their experience on the call may be different from what was recorded.

Please note the term “remote party”. This term denotes the caller or recipient the customer is talking to. The “customer” is your VoIPcloud customer.

There will be four scenarios you will find when reviewing the call recordings (these results are assuming the customer is consistently complaining of call quality issues and Step 1. has been done):

Step 3. Gather evidence

Most of these call quality issues will be due to packet loss on a leg of the call. In order to get them resolved, we need to engage the ISP in question. The ISP will not entertain a fault report without solid data showing a problem.

You will need to help the customer gather this data by doing MTR traces and saving the trace results. Remember to run the trace for at least a few hours to get a large enough data set to prove the problem.

Please note that an MTR is the same as a tracert (traceroute) done over time. VoIPcloud recommends using software like WinMTR or Pingplotter to gather this information. Also, remember to get the customer to enable ping/ICMP response on WAN on their routers so we can get clear information back. The registration server is the server address the customer’s devices are registered to.

Below is an example of an MTR result (note the loss percentage on the last two hops).

• Scenario 1: Due to the problem being with the customer’s download route, you will need to engage VoIPcloud support to trace back to the customer’s network. You can still to anMTR to the registration server to test their outbound route (if there is a problem with the connection, the problem could be both ways). After the agreed-upon monitoring period, VoIPcloud support will send you the result of the MTR and you will be able to proceed to Step 4.
• Scenario 2: Due to the problem being likely isolated to the service the caller is using, we would expect that the symptoms will not be universal. Further checks with the affected callers need to be done to try and isolate a specific mobile carrier, a specific landline carrier, or a specific location that is affected.
• Scenario 3: If the problem is isolated to leg 4 (and therefore the customer’s upload route), then there needs to be an MTR done to prove the packet loss on the upload connection to the VoIPcloud servers.
• Scenario 4: This scenario implies a global problem and further checks need to be done to establish the scope of the problem. Check your other customers and find out if they are having the same symptoms and if they are hosted on the same server. You will also want to check the VoIPcloud service status section on the portal or contact VoIPcloud.

Step 4. Follow up and escalate

You should now have sufficient evidence of the problem and will need to get this escalated to VoIPcloud or to the relevant ISP or carrier (via caller or VoIPcloud support).

• Scenario 1: You will likely find packet loss on the MTR results VoIPcloud support gives you. If you do, you will need to liaise with the customer to lodge a fault with their ISP about their inbound route having packet loss. If you find packet loss on their outbound route as well, be sure to forward this information to support the claim of a fault in their connection. Note that you could also try a different internet connection such as a 4G wireless internet connection. This may help to change the routes the data is taking and effectively route around the compromised routes.
• Scenario 2: Depending on the scope of the affected caller, you may need to tell the affected party that their service is compromised or you may need to escalate this toVoIPcloud support to follow up. For example, if only one mobile caller has an issue, it's likely it's their phone or the mobile tower they are connected to. If the problem is with all Telstra mobiles, then we may need to escalate a fault through our upstream providers to either resolve the issue or route around it.
• Scenario 3: The follow-up would be the same as scenario 1. A fault needs to be
  logged with the relevant ISP using the trace results as supporting evidence. As with Scenario 1, you can try using a different internet connection to change the routes their upload data is using.
• Scenario 4: This type of situation is very rare and will need to have further checks done to prove the problem. Verify the scope of the issue as much as you can and check withVoIPcloud support. You should now have sufficient evidence of the problem and will need to get this escalated to VoIPcloud or to the relevant ISP or carrier (via caller or VoIPcloud support).