If you only have:
- a capture taken at one point somewhere in the call path, AND
- you have RTCP Sender Reports being sent in both directions, AND
- the LSR in one direction (B->A) corresponds to a the timestamp in a previous report in the opposite direction (A->B),
You can work out the network roundtrip propagation delay, which is the network time from the capture point to B and back again.
If you do this from a capture taken at A, this will be all the way to B and back again, i.e. twice the end-to-end latency (assuming both directions take roughly the same amount of time).
This is described in RFC 3550 (the update to RFC 1889) at the end of section
6.4.1. Wireshark has supported doing this calculation if it has the necessary information for a few releases. There are some RTCP protocol preferences you should set to see this calculation happening. If the calculation is done, the result will appear as expert info.
Because this method matches the timestamp of the reports, you shouldn't see any false calculations because of lost RTCP sender reports.
Martin
On Sat, Apr 12, 2008 at 11:56 PM, Fabiana moreno <
fvmoreno@xxxxxxxxx> wrote:
AHHHHHHHHHHHHHHHH!!!!!!!! Thanks!!! and if i want to calculate the end-to-end delay or latency of the packets, where end to end or latency mean; the time that takes the packet to travel from the server to the client, can i use something similar?...but then ...i will have to deal with packet loss..if the packet is loss then it wouldnd be counted.. Thank you very much your help!! i really appreciate it
Fabiana moreno wrote:
> Thanks again...so this actually answers what i meant in my
> question....the sequence number is unique within the capture...so it´s
> like my identifier...
The sequence number is 16 bits, so it can only be unique within the RTP
session if fewer than 65536 packets are sent. You should look for
"gaps" in the sequence number, such as going from sequence number 60410
to sequence number 60412 or later.
Presumably the sequence number will "wrap around", so it will go from
65535 to 0. Any "lost packet" analysis you do must take that into
account. The best way to do that would probably be to, for each RTP
packet other than the first packet, subtract from it the sequence number
of the previous packet, and take the result modulo 65536; if the result
is something other than 1, you have missing packets.
If, for example, you see a packet with a sequence number of 65535 and
then a packet with a sequence number of 2, the difference will be 2 -
65535, or -65533. -65533, modulo 65536, would be 65536-65533, or 3.
In C, with GLib, the way to do that would be
guint16 previous_packet_seq, current_packet_seq, seq_diff;
seq_diff = current_packet_seq - previous_packet_seq;
where "previous_packet_seq" is the sequence number of the previous
packet and "current_packet_seq" is the sequence number of the current
packet; in that case, "seq_diff" will be set to the difference between
the sequence numbers of the packet, modulo 65536.
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users