Hello, Voiper.

You always look at the final destination first, then look upstream for the first hops that don't show similar loss. If you're not seeing packet loss at the final destination, then none of the other intermediate data matters - those are just routers delivering data. We have an analogy on why this happens like this in our VoIP troubleshooting guide. If your final destination is showing 1% loss, then that's the number you report - not hop 4 that's showing 40% loss, or hop 1 that's showing no lost packets.

There are certainly nuances to this. You should definitely make sure you're examining enough data to have your packet loss numbers be statistically relevant - if you're only looking at 100 samples, then that's not statistically enough data to trust the 1%, 0%, 2% and 5% numbers. If you're looking at 1000 samples, then you start to get more statistical redundancy that makes you believe the numbers more.

So, let's say you're looking at 10000 samples and you're seeing 2% at hop 2, 0% at hop 3, 5% at hop 7, 0% at hop 10, and 1% at the final destination (hop 11).

First, you have to look at the difference between 0% and 1% and see if these are really close with rounding (let's say you have 55 lost packets at the final destination and 45 at hop 11). Those are pretty close to the same, and you'd have to look upstream for roughly 1/2 of 1% packet loss and see which is the first hop that doesn't show that same loss.

Another scenario is that you've lost 1 packet at hop 11, but 145 at hop 12 - that's pretty statistically compelling - you know hop 11 isn't the culprit. If you have other intermediate hops that also have ~145 lost packets, then you start to suspect the return route. If hop 9 and hop 12 have ~145 lost packets, but hop 10 and 11 have < 10, then you suspect that the packets from hop 12 are going back through a different provider than hop 10 or 11, but hop 9 is using that same one. In that case, tracing the route back from the other end is hugely helpful (if you have control of the destination and you want to do that with PingPlotter Pro, you can set up a remote agent at the far end and trace both directions in one instance of Pro).

VoIP does not retransmit - and neither does PingPlotter. If a packet doesn't make it, it doesn't make it. In PingPlotter, this is shown as a lost packet. In VoIP, it causes a loss of voice data, which can sometimes be smoothed over, and sometimes not (especially if there are enough of them).

I'm not enough of a VoIP expert to validate your theory on packet loss interrupting DTMF tones. DTMF is built to be noise-resistant, though, and I'd be surprised if a single lost packet would cause that sort of problems. Are you using G.711 or G.729? G.729 is a lot more susceptible to packet loss and network call quality issues.

If you want us to look at your situation in specific, collect a few hours of data (especially good if you do that when you're using the line and can report in problems through the comment feature) and then send the .pp2 save file to support@pingplotter.com. We can analyze it, extract the best picture to show what we think is important, and then post a picture back here (or just keep it in email if you prefer).

- Pete