Hello everyone. I have a trace file of a mirror port of a phone. Where the problem is: Phone A can not hear the phone B. Phone B can listen to phone A. The trace file that have captured, belongs to Phone A. In fact, the audio from the phone B I can hear it through wireshark. What caught my attention is that wireshark indicates that 100% of packets RTP from Phone B to Phone A are Lost and indicate the state "Wrong sequence number".
it is possible that "something" in the network between 2 phones (something like a firewall)is causing this loss.? here is the pcap File asked 02 Sep '16, 12:02  protosolid edited 02 Sep '16, 13:37 |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
Please upload your capture (including the protocol carrying the SDPs) to Cloudshark or to any file sharing service and edit your Question with a login-free link to the file. Analysis by a screenshot is almost impossible.
RTP detection and analysis is under constant evolution in Wireshark. The fact that SSRC is identical for both direction is weird alone, this is extremely rare in real life, and so Wireshark may be confused by that if it is true. But looking at the time offsets, it more likely that what you have captured are duplicates of a single RTP stream.
Too many bad things happened simultaneously:
Wireshark indicates -100% packet loss in forward direction because all the RTP packets in this direction are duplicated and the analysis algorithm compares the number of packets to the difference between last and first RTP sequence number, so it gets 200% of the expected packets, which means 100% extra packets, which means -100% loss.
Wireshark indicates 100% packet loss in reverse direction most likely because you haven't chosen the "reverse" direction before asking for RTP analysis (you have to click one stream in the list first, and then click the other one while holding Ctrl, the one clicked without Ctrl will become the Forward direction and the one clicked with Ctrl will become the reverse direction).
Wireshark's RTP analysis shows the SSRC of the forward direction also in the summary of the reverse direction
In reality, both RTP directions are present in the capture and have distinct SSRCs, normal sequence numbers, packet size, and RTP timestamps, and their destination sockets match those indicated in the corresponding SDPs.
So even if something (like a firewall) prevents RTP packets sent by phone A from reaching phone B, this capture doesn't prove that directly.
However, looking at packet's MAC addresses, I can see that the SIP and RTP packets towards phone A come from a Cisco box, while SIP and RTP packets from phone A are sent to an HP box. This means that at least a part of the path between phone A and phone B (or the SIP server between them) doesn't go through the same boxes, so if one of them needs to see A->B UDP traffic in order to permit the B->A one, it could explain the one-way audio.
But such explanation collides with your description saying that it is the phone A at which you capture which doesn't play the audio. So the question is how exactly did you mirror the port A - have you mirrored both directions of a single port or a whole VLAN?
As only the RTP towards 10.31.0.20 is duplicated, while the SIP packets to the same destination are not, nor any packets sent by 10.31.0.20, I guess the capture setup is correct, the packets are duplicated somewhere else, and the fact that they are duplicated is the reason why the playback at phone A fails.