Raghul,
That question makes no sense.
There's one packet loss count per RTP stream. (And there are usually two RTP streams for a bi-directional voice conversation). It's the counter for lost packets in direction from sender to receiver, calculated at the particular point where the Wireshark trace has been taken.
It's your capture location setup that decides whether this point is located closer to the sender or closer to the receiver.
It's related to a stream at the capture location, not to a device at an endpoint.
Regards,
Lars
________________________________
From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Raghul Prasanna
Sent: mardi 6 décembre 2011 12:07
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] packet loss and network issues - wireshark
Thanks Lars,
>>Yes, the packet loss count is based on the RTP sequence number.
Basically, packet loss counter is increased by (SEQ_N - SEQ_N-1 - 1), where N and N-1 are the currently and previously received RTP packets of that same tream, respectively. This value can be negative.
OK this is in received direction, what about in Transmit direction please?
Raghul
________________________________
From: "RUOFF, LARS (LARS)** CTR **" <lars.ruoff@xxxxxxxxxxxxxxxxxx>
To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx>
Sent: Monday, 5 December 2011, 10:11
Subject: Re: [Wireshark-users] packet loss and network issues - wireshark
Hi,
> But what I am failing to understand is where is wireshark getting the sequence number, because UDP doesnt have any sequence number, then is it the RTP packet number?
Yes, the packet loss count is based on the RTP sequence number.
Basically, packet loss counter is increased by (SEQ_N - SEQ_N-1 - 1), where N and N-1 are the currently and previously received RTP packets of that same tream, respectively. This value can be negative.
> MAX Delta - Is this max gap between packets for a stream? If so what will be the best value?
Yes.
If there's no silence suppression, the expected value is the "framing" used for that call and codec.
Typical values are 20ms or 30ms for G.711 for example.
More precisely, the expected value is the difference between RTP timestamps, taking into account the Codec sampling rate, and expressed in miliseconds. This is usually constant throughout a call.
Care must be taken if the stream contains silence frames, comfort noise, etc.
Wireshark doesn't handle them too well in the jitter or loss calculations and you might get unexpected results.
Lars
________________________________
From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Raghul Prasanna
Sent: dimanche 4 décembre 2011 15:49
To: wireshark-users@xxxxxxxxxxxxx
Subject: [Wireshark-users] packet loss and network issues - wireshark
Hello,
Sorry if its a simple question, I am bit new to wireshark.
I am trying to find out network issues, because the audio quality is bad during peak hours. When I capture on an interface and do stream analysis of RTP stream I see some streams showing more than 70% packet loss.
When I capture on an inteface I believe the wireshark captures audio in both the directions and I believe wireshark detects packet loss based on transport layer protocol, in my case UDP.
Strem analysis of one such stream shows lots of wrong sequence number, which would again indicate packet loss. But what I am failing to understand is where is wireshark getting the sequence number, because UDP doesnt have any sequence number, then is it the RTP packet number?
How would wireshark know packet loss in TX direction based on packet loss, because I see packet loss for streams going from my interface to the far end?
MAX Delta - Is this max gap between packets for a stream? If so what will be the best value?
Thanks,
Raghul
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
