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

[Martin Mathieson <martin.mathieson@xxxxxxxxxxxx>]

The other RTCP preference you'll need to switch on is 'Show relative 
roundtrip calculations'.  In case you don't have all of the signalling 
traffic present in your trace, I'd also suggest ticking 'Try to decode 
RTCP outside of conversations'.

You'll only get roundtrip calculations happening if:
- both sides send sender or receiver reports
- those reports have the relevant fields properly filled in

You can detect that the calculation has been done by either:
- filtering on RTCP packets (display filter = rtcp) and looking at the 
info column, OR
- filter directly on the calculation result (display filter = 
rtcp.roundtrip-delay)

If you are capturing on the same machine as one of the clients is 
running, you can expect to see 0 or near-0 delays to the local client, 
and non-0 towards the remote client.  150ms is the latency figure often 
quoted the maximum usable delay.  Note that the figure of this 
calculation is a whole roundtrip, i.e. there and back...

I believe that the commonly-used, free SIP and H.323 clients don't have 
a good record of properly sending these reports.  Please read carefully 
the section in the RFC and compare what it says with what you find 
clients are sending.

Regards,
Martin



Andreina Toro wrote:

> 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 
> <mailto: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>
>     > <mailto: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>
>     <mailto:Wireshark-dev@xxxxxxxxxxxxx
>     <mailto:Wireshark-dev@xxxxxxxxxxxxx>>
>     >     http://www.wireshark.org/mailman/listinfo/wireshark-dev
>     >
>     >
>     >------------------------------------------------------------------------
>     >
>     >_______________________________________________
>     >Wireshark-dev mailing list
>     >Wireshark-dev@xxxxxxxxxxxxx <mailto:Wireshark-dev@xxxxxxxxxxxxx>
>     >http://www.wireshark.org/mailman/listinfo/wireshark-dev
>     <http://www.wireshark.org/mailman/listinfo/wireshark-dev>
>     >
>     >
>
>     _______________________________________________
>     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
>