Hello, I have recently introduced SIP into our network and I'm having a hard time tracking down some intermittent phone quality issues. Before, I can track down my issues I need to understand why Wireshark is behaving the way it is. when I run a capture on my SIP proxy box and open up Telephony->VOIP Calls and find a call that I'm interested in listening to. Sometimes when I click on the file and hit play stream the RTP player opens up but there is nothing in the box that shows source address port etc....so I cannot play the file why is that? Then I will find other calls that show codec is unsupported as there g729 calls. I found an article on WS showing the process to do this is that still valid as I'm running 2.1.1? On my PBX there is a section where I can turn on voice stats and there are calls with a large number of packet loss. At the time there's no congestion on the WAN link or issues with the phone's LAN switchport so I'm trying to track down what's the root cause of my packet loss. I've got high loss with G711 and G729. I am new to SIP so if anyone has any pointers please let me know. Thanks, asked 06 Oct '17, 12:51  rock90 |
One Answer:
One, this is somewhat of a grab bag of questions, probably more suitable for wireshark-users mailing list, but here goes with some answers.
It may take a lot of drilling down into various system parts to get all blockages out. answered 07 Oct '17, 01:21  Jaap ♦ |
SIP is just the control part. RTP is what you have to concentrate at.
G.729 did not work for me even in 2.4.1, I had to install 2.5.0-something to get the G.729 player to work.
Newer codecs cannot be played at all either because their patents are still in force so they cannot be bundled to GPL software, or because no one has implemented them even though they aren't patended. But that shouldn't bother you as you only really need to playback the captures if you are sure that the network is perfect and you want to confirm that the sound inside the RTP stream was garbled already when the RTP packet was being formed.
As @Jaap wrote, voice is time critical. Each VoIP equipment sets up its own compromise between requirements to the smallest possible microphone-to-speaker delay and to the highest possible tolerance to jitter (irregularity of packet delivery times between source and destination) by intentionally delaying playback of received packets by temporarily storing them in a buffer. So if a given RTP packet arrives too late to be played in its due time, there is an audible gap in the playback.
Therefore, even if no RTP packets are actually lost, they may be reported as such by the codec (and thus in the statistics of your PBX), because it didn't have them when it needed them.
In the Wireshark player you can simulate a jitter buffer size to see and hear how that stream would be handled by a receiver with such jitter buffer size, but you usually do not know what size the receiver in question actually uses, leaving aside that it may even dynamically change.
So I'd capture right in front of each of the two endpoints of the RTP flow and compare the jitter and RTP sequence numbers at sending and receiving side. If some RTP sequence numbers are missing at receiving side although they exist at the sending side, there is a real packet loss in the network. If the RTP packets come to the receiving side irregularly, or even do not come in monotonously ascending order of the sequence numbers, find out where this comes from. Years ago I've seen devices delaying some packets for seconds which must have been a bug, but delays above 50 ms may already cause audio problems depending on settings of the receiver's dejittering buffer. Multiple paths through networks, large packets on slow lines, and wrongly configured QoS (packet prioritization) rules are most frequent causes of jitter.
Thank you both for responding.