Andreina,
If the RTP session is properly exchanging RTCP sender & receiver
reports, wireshark can calculate the network roundtrip delay in both
directions (i.e. the time in milliseconds it takes the RTCP reports to
travel from the point of capture to either RTP endpoints and back
again). To turn this on you need to enable some RTCP protocol
preferences (set the min-reported delay to 0).
This calculation is described in RFC 3550, section 6.4.1.
Regards,
Martin
Andreina Toro wrote:
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
<mailto: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 <mailto:Wireshark-dev@xxxxxxxxxxxxx>
http://www.wireshark.org/mailman/listinfo/wireshark-dev
------------------------------------------------------------------------
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
