ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

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

From: "Andreina Toro" <andreina.toro@xxxxxxxxx>
Date: Wed, 6 Sep 2006 10:21:04 -0400
I´m amazed how fast you guys answer! It´s incredible!... Thank you!..
 
I´m not too familiarized with Wireshark so maybe my questions have simple answers.. sorry for any inconvinience..
 
Mr. Martin I already set the min-reported delay to 0, now where do I have to expect the changes of this preference?
 
Another question, where using Wireshark can I see the network roundtrip delay in both directions? And one way delay should be < 150ms right?
 
thanks a lot!
Andreina 

 
On 9/6/06, Martin Mathieson <martin.mathieson@xxxxxxxxxxxx> wrote:
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
>
>

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