Wireshark-dev: Re: [Wireshark-dev] question about RTP Streams - [ SPAM - Bayesian] Bayesian Fil
From: "Andreina Toro" <andreina.toro@xxxxxxxxx>
Date: Mon, 11 Sep 2006 14:50:59 -0400
Hi ronnie, thanks for helping me...
I´m a little lost.. In general I undestand what you mean.. the total latency A <-> B will be the sum of the latencies. But what does it mean PSH when you said... TCP PSH
to A?
Another thing, I´ll be taking the measures somewhere on the path between A and B but I´m not sure if I can find TCP sessions for both A and B in the trace?... Here I attach you a file with a picture of where I´ll be measuring, if you could take a look I´ll be thankfull.. I´ll be listening to everything that goes trhough and I will only save to a file VoIP traces, I`ll filter them with RTP Streams. How can I measure the latency as you said? because wireshark already gives me the % of packet loss, jitter, etc, but not latency.
Thanks so much,
Regards,
Andreina
On 9/8/06, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
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
> >
>
>
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Attachment:
ronnie.doc
Description: MS-Word document
- Follow-Ups:
- References:
- Re: [Wireshark-dev] question about RTP Streams
- From: Andreina Toro
- Re: [Wireshark-dev] question about RTP Streams
- From: Jaap Keuter
- Re: [Wireshark-dev] question about RTP Streams
- From: Andreina Toro
- Re: [Wireshark-dev] question about RTP Streams - [ SPAM - Bayesian] Bayesian Filter detected spam
- From: Miha Jemec
- Re: [Wireshark-dev] question about RTP Streams - [ SPAM - Bayesian] Bayesian Filter detected spam
- From: Andreina Toro
- Re: [Wireshark-dev] question about RTP Streams - [ SPAM - Bayesian] Bayesian Filter detected spam
- From: ronnie sahlberg
- Re: [Wireshark-dev] question about RTP Streams
- Prev by Date: Re: [Wireshark-dev] What's the state of the Meta/LUA plugins? How to continue?
- Next by Date: Re: [Wireshark-dev] Need info of "recently" added: GNUTLS, KFW, NETTLE, LUA and PortAudio for the Devel Guide and elsewhere
- Previous by thread: Re: [Wireshark-dev] question about RTP Streams - [ SPAM - Bayesian] Bayesian Filter detected spam
- Next by thread: Re: [Wireshark-dev] question about RTP Streams - [ SPAM - Bayesian] Bayesian Filter detected spam
- Index(es):