Wireshark · Wireshark-users: Re: [Wireshark-users] Pb?, Max Delta, Max Jitter, Mean Jitter colums in wireshark's RTP stream analy

["Lars Ruoff" <lars.ruoff@xxxxxxxxxxxxxxxxx>]

So where do the  
> 	Max Delta (ms) - 4119.77 [320.14]
> 	Max Jitter (ms) - 1.80 [70.12]
come from?

PT=0 is PCMU (G.711 my-law), voice.
PT=101 is user-defined, most probably DTMF events.
If your call has DTMF or other events, you can probably ignore the jitter
around these events.
Those events are decorrelated with the steady background voice flow, but
Wireshark only sees the deltas from packet to packet so gets confused with
this.


Lars


> -----Original Message-----
> From: wireshark-users-bounces@xxxxxxxxxxxxx 
> [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of gdonts
> Sent: mercredi 27 août 2008 11:28
> To: 'Community support list for Wireshark'
> Subject: Re: [Wireshark-users] Pb?, Max Delta, Max 
> Jitter,Mean Jitter colums in wireshark's RTP stream analysis
> 
> Thanks Lars,
> 
> Max Delta - no silence suppression in place, so high Max 
> Jitter - high value.
> 
> I've gone through the packet list in the RTP stream analysis:
> - Max Delta packets aren't surrounded by unusual ones (the 
> top 5 max deltas all had packets going back to about 20 ms 
> immediately before & after), and there are only 5 packets 
> with max delta > 50 ms, 23 > 30 ms (out of 170,000 packets captured). 
> - Any higher Jitter packets seem to generally go with a 
> status message "Payload changed to PT=0" or "Payload changed 
> to PT=101". Any idea what they are?
> 
> any suggestions on the status message, and what else 
> Wireshark can tell me about this issue?
> 
> 
> 
> thanks,
> 
> -----Original Message-----
> From: wireshark-users-bounces@xxxxxxxxxxxxx
> [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Lars Ruoff
> Sent: 26 August 2008 15:02
> To: 'Community support list for Wireshark'
> Subject: Re: [Wireshark-users] Pb?, Max Delta, Max 
> Jitter,Mean Jitter colums in wireshark's RTP stream analysis
> 
> Hi,
>  
> The 'X' in Pb is only a hint.
> It will be put in the summary whenever there is anyone of the 
> following issues detected on the stream: Out of order 
> sequence numbers (including missing ones) and payload type 
> changes. (Are there any other? I don't remember). It doesn't 
> even check about Max delta and jitter.
> 
> Concerning your sample:
> Lost packets - Few - not a problem.
> Max Delta - High! - May be a problem (indicates voice gaps) - 
> unless you are using voice activity detection  /silence frames.
> Max Jitter - Quite high! (as compared to Mean jitter) - May 
> be a network issue.
> 
> I suggest you drill down to in-depth "RTP-Analysis" for any 
> streams sticking out by any of the above values and then go 
> through the packet list to see any incoherencies.
> 
> Sorting the RTP-Analysis columns by "Delta" or "Jitter" 
> (descending) may give you a quick view at the max values.
> Try to look for the packets with high "Delta" and explore the 
> immediate time neighbourhood of these packets.
> You might see a gap followed by a sudden burst of packets 
> (near zero Delta).
> Then you have a network problem (packets are buffered somewhere).
> 
> Regards,
> Lars
> 
> 
> ________________________________
> 
> 	From: wireshark-users-bounces@xxxxxxxxxxxxx
> [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of gdonts
> 	Sent: mardi 26 août 2008 15:35
> 	To: wireshark-users@xxxxxxxxxxxxx
> 	Subject: [Wireshark-users] Pb?, Max Delta, Max 
> Jitter,Mean Jitter colums in wireshark's RTP stream analysis
> 	
> 	
> 	Hello,
> 	 
> 	I have a conference bridge (Avaya S6200 on SCO Unix) 
> which I'm getting intermittent reports of 'garbled' audio. 
> The conf bridge uses G.711
> u- or a-law, and incoming audio is provided by an ITSP (who 
> have media gateways (I believe Cisco) installed in a variety 
> of locations that connect to PSTN).
> 	 
> 	I've also got a PSTN connection into the bridge, where 
> there are no reports of poor audio, so I suspect something on 
> the network (ie this is only effecting calls that come in via 
> SIP/VoIP).
> 	 
> 	I have the following connectivity:
> 	 
> 	Unix conference bridge <-> Cisco 2960 switch <-> 
> Juniper SSG5 firewall <-> datacenter's BGP <-> public 
> internet <-> ITSP's own POP <-> ITSP's own network <-> local 
> media gateway in local carrier datacenter
> 	 
> 	I can't install Wireshark on the SCO Unix bridge (old 
> 7.1.1 version of OS), so I've got Wireshark running on a 
> Windows server connected to a Port mirror (or port span) so 
> it's taking a copy of all the traffic going to the Unix 
> conference bridge. I also know that Wireshark can't know the 
> state of the various points on the network, so I'm only 
> posting info on the end-point (ie at the conf bridge)
> 		 
> 	I'm also open to any general suggestions that anyone 
> has, but I know this is a Wireshark maillist, so what I'm 
> specifically trying to find out about Wireshark (bless it!) is:
> 	I've used the Statistics -> RTP -> Show all streams to 
> get a view of the various RTP streams of reported bad audio. 
> I've a vague idea of the principles behind calculating 
> jitter, but when I see an 'X' in the 'Pb?'
> column is this definitely a problem or just a suggestion that 
> it might be an issue? The following are the values for one 
> sample call with reported bad
> audio:
> 	 Column - forward value [reverse value]
> 	Lost - 0 (0.0%) [47 (0.0%)]
> 	Max Delta (ms) - 4119.77 [320.14]
> 	Max Jitter (ms) - 1.80 [70.12]
> 	Mean Jitter (ms) - 0.02 [0.30]
> 	Pb? - blank [X]
> 	 
> 	The above is from a sample of about 60 minutes, so is a 
> good representation.
> 	 
> 	So which of the above values (if any) should I be 
> worried about (ie would affect audio quality)?
> 	 
> 	Any information/suggestions/comments appreciated.
> 	 
> 	 
> 	Regards,
> 	 
> 	gdo
> 
> 
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> https://wireshark.org/mailman/listinfo/wireshark-users
> 
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> https://wireshark.org/mailman/listinfo/wireshark-users