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

Hi Jaap,  when you say " 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?,

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