This is our old Q&A Site. Please post any new questions and answers at

Wireshark version V1.12.8

I have captured a wireshark trace which showed a payload issue (garbled) as reflected in RTP Stream Analysis when played using the Player button. Good.

Then I saved this RTP stream using "Save Payload As ..." button and named it as (Format: .au extension and Channel: forward).

Upon opening the using windows media player the captured speech was played clearly without any issue i.e no garbling was heard from the saved audio file. Opening the audio using CoolEdit2000 also produce no issue with the saved wave file.

My question is: How come there is a difference with playing the RTP Stream Analysis and saving the RTP Payload stream as an audio file in wireshark?

Not sure whether anyone has experienced this issue as I had. Thanks for any feedback.

Note: Have upgraded to wireshark version to V2.0.1 but the discrepancy persists?

asked 21 Jan '16, 17:09

SunnyK's gravatar image

accept rate: 0%

The reason is that while the RTP player imitates the behaviour of a real gateway device by simulating use of a de-jittering buffer, which is something all gateway devices have to use, the Save Payload As... doesn't do this.

So the difference you describe indicates that you wanted to use Save Payload As... to document some issue with garbled sound, assuming that the source of the RTP or of the audio contents itself was faulty, but that the real cause of the garbled sound is actually a network issue.

The travel time of any packet through the network from the source to the destination is not the same for all packets. These deviations of travel time of individual packets from the mean travel time of all packets in the same stream are called "jitter". Due to its existence, it would be a bad idea to start playing the contents of any received RTP packet immediately as it comes, because if it would take the next one longer to get to you, you'd have finished playing the contents of the first packet and have nothing to play until the next one would arrive, causing a garbled sound at the output. To prevent this, gateways intentionally do not start playing packets immediately after reception of the very first one, but first build a queue of several packets. The longer the queue, the better tolerance to delayed packets, but the worse the user experience, so different developers use different strategies and even adjust the queue sizes dynamically.

The queue size is also an issue. At multi-channel gateways,

  • you cannot give an unlimited amount of memory to each channel,

  • the playback sample rate is usually common for all streams.

So if the source of the packets uses a slightly faster sample rate than its recipient, the playback queue grows with time, and if its size is limited, you have to drop those incoming packets which come while there is no space in the queue (or better use some smoothing techniques, dropping individual samples rather than whole packets), resulting in audio quality deterioration.

So when you encounter a garbled sound issue, but Save Payload As... saves a clean sound and Wireshark statistics shows no lost packets in the stream (i.e. the RTP sequence numbers of the packets in the stream are monotonously rising by one), look at the times elapsed between packet arrivals. If they differ heavily (in fact, any jitter values of tens of milliseconds, i.e. comparable to the packetization time, need attention) already at the point of capture, it means that you have to have a look to the dejittering buffer parameters at the receiving gateway. If you cannot see any interesting jitter values (jitter lower than packetization time usually doesn't make any real life trouble), but Wireshark tells you that the sample rate differs from the expected one (which is 8000 Hz for most traditional audio codecs but it is not a law of physics), it may also be that the jitter buffer underruns (new packets arrive too slowly due to lower sampling rate at the sending side) or overruns (new packets arrive too fast).

In the RTP player, you can imitate the de-jittering buffer behaviour of a particular gateway, if you know that gateway's settings, by setting the size of dejittering buffer in the RTP player window. Or you can switch the dejittering buffer simulation off by setting Playback Timing to Uninterrupted mode (i.e. same behaviour like Save Payload As...) if you want to check "by ear" whether jitter or something else is the cause of the issue. You can also set Playback Timing to Use RTP Timestamps (roughly, playing the packets as they looked at the sender), which more or less can only reveal sender's issues with timestamping.

More sophisticated dejittering buffer strategies are not implemented in the RTP player (yet?).

permanent link

answered 22 Jan '16, 01:35

sindy's gravatar image

accept rate: 24%

edited 22 Jan '16, 14:17

Thanks sindy for the informative reply.

After posting my question online I have a discussion with the customer IT staff and eventually the problem was resolved. It was due to delay between sites which led to the garbled sound.

Your reply reinforces my understanding of jitter buffer and wireshark as a tool to demonstrate it.

Thanks again for your reply. Appreciate it. Have a nice day.


(24 Jan '16, 20:17) SunnyK

@SunnyK, thank you for upvoting my answer, but to mark an answer as useful, you (because nobody else can do it) have to use the checkmark icon instead of the "thumbs up" one. This makes the question appear as "answered usefully" in the question list. This is how this site works.

(25 Jan '16, 01:24) sindy

Hi sindy,

I had selected the checkmark icon.



(26 Jan '16, 14:51) SunnyK
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 21 Jan '16, 17:09

question was seen: 1,421 times

last updated: 26 Jan '16, 14:51

p​o​w​e​r​e​d by O​S​Q​A