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

["Andreina Toro" <andreina.toro@xxxxxxxxx>]

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