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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > > > [email protected] > > > > > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Wireshark-dev mailing list > > > [email protected] > > > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > > > > > > > > > > > _______________________________________________ > > > Wireshark-dev mailing list > > > [email protected] > > > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > _______________________________________________ > > Wireshark-dev mailing list > > [email protected] > > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > > > _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
