Re: packet loss and network issues - wireshark

["RUOFF, LARS (LARS)** CTR **" <lars.ruoff () alcatel-lucent com>]

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 () wireshark org [mailto:wireshark-users-bounces () wireshark org] 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 () alcatel-lucent com>
To: Community support list for Wireshark <wireshark-users () wireshark org> 
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 () wireshark org [mailto:wireshark-users-bounces () wireshark org] On Behalf Of Raghul 
Prasanna
Sent: dimanche 4 décembre 2011 15:49
To: wireshark-users () wireshark org
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 () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request () wireshark org?subject=unsubscribe



___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe