Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] question about RTP Streams

From: "Andreina Toro" <andreina.toro@xxxxxxxxx>
Date: Wed, 6 Sep 2006 09:19:42 -0400
Thanks Miha for your answers, they were really helpful, I have a different question now. You said that "Wireshark can not calculate this end-to-end delay since the only information is has are the timestamps of the packets as they were captured", I´ve read that in the RTP Header in bytes 5 to 8 there is the timestamp which "reflects the sampling instant of the first octet in the RTP data packet. The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations", so I don´t have clear why there is no way to calculate the end-to-end Delay, the timestamp you refered to is the same I´m talking about? or we can access manually the time of creation of tha package and wireshark has the time of capture?. Sorry for my confusion.. maybe the answer is very simple.. but I don´t see it..
 
My problem is that for part of my thesis (to graduate of Electronical Engineering) I have to mesure the Quality of Service parameters of VoIP, and then when there is bad QoS activate some alarms and so on... So I need to be able to calculate or manipulate the "delay, jitter and packet loss" of a call (it can be a summary or an average). Do you have an idea how can I solve this problem of getting the Delay information?
 
Thanks so much for your time,
 
Regards,
Andreina

 
On 9/5/06, Miha Jemec <m.jemec@xxxxxxxxxxx> wrote:


> In Wireshark the Max Delta represents the DELAY?, are these concepts
all right?

No, what you mean with DELAY is end-to-end delay which should be under
150ms to have good quality. Wireshark can not calculate this end-to-end
delay since the only information is has are the timestamps of the
packets as they were captured. Max Delta just represents the maximum gap
between two consecutive packets. In case of g.711 codec and 20ms
packetization this would mean, that packets should come in gap of 20ms
and in the ideal case, without any jitter, also the Max Delta would be
20ms. But because of the jitter one packet will come later and the Max
delta will increase.

Regarding the Max and Mean jitter be aware that jitter calculations
follows the specification of RFC1889 saying:

"The interarrival jitter is calculated continuously as each data
  packet i is received from source SSRC_n, using this difference D for
  that packet and the previous packet i-1 in order of arrival (not
  necessarily in sequence), according to the formula

                   J=J+(|D(i-1,i)|-J)/16
"

in other words, what you see in the table for jitter are not absolute
values of last two packets. Max jitter is the highest jitter which appeared.

This is how the first implementation of this function in ethereal
worked. I didn't look in the code, but I think it is still more or less
the same (otherwise someone will hopefully correct me).

Regards, Miha

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev