We are troubleshooting VoIP quality issues. To do this we made a test call while doing a capture on the port that the phone is connected to as well as the port that the PBX switch is connected to. When analyzing the RTP streams we notice that for two of the streams it shows a negative packet loss. There is a total of 47580 packets and a total lost of -23790 (-100.0%). Then another stream shows a different number of packets but still shows -100%. I do know that Wireshark will display packet loss as a positive number as there is one other stream that shows it lost 2 packets out of 18574. Why is it that for these two streams it is showing negative packet loss? asked 09 Jul '15, 12:21  izahorik edited 09 Jul '15, 17:09 |
2 Answers:
I suspect the problem is that one side reset its sequence numbers during the call. Effectively it's the same as bug 10665. I don't know a lot about RTP so I haven't been able to progress on that bug. answered 10 Jul '15, 07:42  JeffMorriss ♦ So does that mean that there actually isn't any packet loss? (10 Jul '15, 07:44) izahorik It's hard to say without seeing either the capture itself or at least the sequence numbers. There's a tshark command in the bug that dumps out the sequence numbers: try doing that and looking for massive jumps (like the one shown in the bug). (10 Jul '15, 09:11) JeffMorriss ♦ Sorry, I tried running the command but it did not give me any output. I did post the capture above as well (https://www.dropbox.com/s/o1sx3jdvwg0kmpn/Phone%20Quality%20710151007.pcapng?dl=0) (10 Jul '15, 12:05) izahorik Your capture file isn't the same problem as that bug's. Your's has wrapping sequence numbers, which is perfectly legal/good, but Wireshark doesn't appear to handle it well for the analysis stuff. Your capture also has changing SSRCs within the same RTP flow and those changing SSRCs changing the sequence number significantly, which is also perfectly legal/good, but I'm not sure if Wireshark's RTP analysis can handle that correctly either. (10 Jul '15, 21:51) Hadriel Actually, I take it back - the problem wasn't the wrapping sequence number - for at least one of the streams, the problem was just that there were duplicate packets... LOTS of duplicate packets. The analyzer got screwed up by it. Once I filtered out the duplicates, the loss percentage became accurate. (11 Jul '15, 05:46) Hadriel |
I've analyzed the big capture file you posted, and I see the -100% packet loss RTP streams - there are two of them, for the same IP:port combo but for two different SSRCs, one for each src->dest direction: one SSRC of 0x087d626e, and one of 0x9c2f450b. These two streams each have duplicate packets. Every single packet is duplicated, and it's completely a duplicate: the Ethernet, IP, UDP, and RTP payloads are all identical. The only difference between each duplicate packet is the capture time. So the Wireshark's RTP analyzer sees twice the number of RTP packets, but with the sequence number only increasing by half that total, and thus its internal math gets all screwed up. I don't know how you got duplicate frames in your capture, but that's the cause. Arguably, Wireshark should detect the RTP sequence number being duplicated, and not count that for packet loss statistics. But that's not a trivial problem to solve for some cases, such as if the duplicates aren't sequential. Another stream in the original capture file shows a -68 packet loss (-1.6%). This appears to be due to the RFC 2833/4733 RTP Events for DTMF packets. Per the RFC, those packets are getting retransmitted twice (three total copies) with the same RTP sequence number, and this is apparently confusing Wireshark's RTP analyzer. Once I removed the retransmitted event packets, it showed no packet loss for that stream. Arguably that's a bug in the analyzer, though it may be hard to fix. answered 11 Jul '15, 07:54  Hadriel |
good question, if you can provide a capture file (google docs, dropbox, etc.) we might be able to answer it.
The PCAP is 250MB as it is everything from the port that my comp/phone is connected to as well as the port from the PBX switch. The capture file can be found below. https://www.dropbox.com/s/o1sx3jdvwg0kmpn/Phone%20Quality%20710151007.pcapng?dl=0
The IP of my phone is 10.10.10.56 The IP of the switch is 10.10.10.11