Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] question about RTP Streams - [ SPAM - Bayesian] Bayesian Fil

From: "ronnie sahlberg" <ronniesahlberg@xxxxxxxxx>
Date: Fri, 8 Sep 2006 21:38:50 +0000
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
>