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

From: Martin Mathieson <martin.mathieson@xxxxxxxxxxxx>
Date: Wed, 06 Sep 2006 15:02:53 +0100
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