Wireshark · Wireshark-dev: Re: [Wireshark-dev] question about RTP Streams - [ SPAM - Bayesian] Bayesian Filter detected spam

["ronnie sahlberg" <ronniesahlberg@xxxxxxxxx>]

while you can not find the end to end latency between the peers A and
B by looking at RTP traffic there may be other ways to measure it.

IF the analyzer is somewhere on the path between A and B and IF you
can also find  TCP sessions for both A and B in the trace you can :

Measure the time between a TCP PSH to A  and the time until you find
an ACK coming back from A  for the data of that PSH segment.
That will give you the latency between the sniffer and A

Do the same for a TCP session for B which gives you the latency
between the sniffer and B.


With some luck the latency A <-> B will be the sum of the latencies
you measured above.


On 9/8/06, Andreina Toro <andreina.toro@xxxxxxxxx> wrote:
> Hi Miha, now I understand why only analyzing RTP streams I can`t get the
> information I need.
>
> Thank you to all for your time.. it´s amaizing your dedication and good will
> helping me!..
>
> Regards,
>
> Andreina (a venezuelan student)
>
>
>
>
> On 9/7/06, Miha Jemec <m.jemec@xxxxxxxxxxx> wrote:
> >
> >
> > > " looking at the
> > > packets you could see a delay of 100ms, which is long but
> > > acceptable"....where in the RTP Streams window you look at the
> > > delay? The only parameters I see are:
> > >       * Src IP addr,Src port,Dest IP addr,Dest
> > >         port,SSRC,Payload,Packets,Lost,Max Delta (ms),Max Jitter
> > >         (ms),Mean Jitter (ms),Pb?,
> >
> > Hi Angelina,
> >
> > wireshark can not measure end-to-end delay, nor the
> > end-to-capture_destination delay. At least not using the RTP protocol or
> > better said, this information is not provided inside RTP protocol.
> >
> > The timestamp inside RTP header increments monotonically, that is true,
> > but this is the information for the receiver side, to know when a sample
> > should be played. This is not (absolute!) time reference.
> >
> > If you take a look inside whole RTP packet you can see, there is no
> > other time information. Nor in the RTP header nor in the ETH/IP/UDP
> > headers. It means you can not know when this packet was sent on the
> > wire. And you can not know when the voice sample was made. And even if
> > this information would be there, would you trust it? How would you know
> > that the clock inside VoIP transmitter and your capture device are well
> > synchronized? Don't forget, we are talking about milliseconds here.
> >
> > Of course there are procedures how to measure ONE WAY END TO END DELAY
> > and all include devices on both sides which are time synchronized (using
> > GPS clock f.e.) but using only wireshark and RTP protocol this is not
> > possible.
> >
> > A simple demonstration of this problem would be:
> >
> > I can send you over the Internet an RTP stream from my VoIP phone or PC.
> > Speech coded with g.711 and 20ms packetization. Let's say, the network
> > will work perfectly today and no jitter will be inserted. It means you
> > will receive one packet every 20ms. No jitter, what about the delay?
> >
> > Now, where do you come from? I'm from Europe, if you live somewhere near
> > me, the delay (the difference in the time between my PC will put a
> > packet on the link and the time you will receive this packet) will be
> > relatively small, let's say 50ms. What about if you come from the other
> > part of the world. Just because of the distance the propagation time
> > will increase and the delay will be higher. In both cases, if you
> > capture this RTP stream and analyze it, you will get exactly the same
> > values inside RTP stream analysis. And if I put a special device after
> > my phone, which will delay every packet for exact 3s before sending it
> > over to you, you will still get exactly the same results. And in all
> > three cases, there is now way for you to know, how much time a packet
> > needed from me to you.
> >
> > I hope this clarifies why only analyzing RTP streams can not give you
> > the information you want. As some already said, there are other ways how
> > to get it.
> >
> > Regards, Miha
> >
> > > Now I understand what end-to-end means, so I can calculate an average
> > > for maximum delay looking at the packages depending on the jitter
> > > buffer in order to get a delay<150ms?, would  that be a good estimate?
> > >
> > > thanks!
> > > Regards,
> > > Andreina
> > >
> > >
> > > On 9/6/06, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
> > >         Hi,
> > >
> > >         "End-to-End" means from the speech source (mic) to the speech
> > >         destination
> > >         (loudspeaker). Now Wireshark can capture half way in that
> > >         path, so it
> > >         cannot predict how the destination endpoint will deliver the
> > >         speech to the
> > >         listner. This is due to the fact that the destination endpoint
> > >         has a
> > >         jitter buffer which delays playout of the media stream. This
> > >         is internal
> > >         to the destination endpoint and not known to Wireshark. So
> > >         looking at the
> > >         packets you could see a delay of 100ms, which is long but
> > >         acceptable. But
> > >         if the jitter buffer is another 70ms you end up with 170ms
> > >         End-to-End
> > >         delay which is too long....
> > >
> > >         Thanx,
> > >         Jaap
> > >
> > >
> > >         On Wed, 6 Sep 2006, 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> 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
> > >         > >
> > >         >
> > >
> > >
> > >
> > >         _______________________________________________
> > >         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
> > _______________________________________________
> > Wireshark-dev mailing list
> > Wireshark-dev@xxxxxxxxxxxxx
> > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> >