VoIP: Mengukur menggunakan Wireshark
The delta is the time difference between the current packet and the previous packet in the stream. max delta is the largest delta value.
Please take a look how Wireshark caluclates the jitter value: http://wiki.wireshark.org/RTP_statistics (search for: How jitter is calculated). The mean jitter value is the arithmetic mean value of all jitter values.
Skew calculation is defined as follows (from: tap-rtp-common.c). max skew is the largest value of all skew values.
/* Calculate skew, i.e. absolute jitter that also catches clock drift
* Skew is positive if TS (nominal) is too fast
*/
statinfo->skew = nominaltime - arrivaltime;
absskew = fabs(statinfo->skew);
if(absskew > fabs(statinfo->max_skew)){
statinfo->max_skew = statinfo->skew;
}
RTP statistics
Saving RTP audio streams
Payload type is G.711 A-law or mu-law
You can save the content of an RTP audio stream to an Au-file directly from Wireshark, if it uses G.711 A-law or G.711 mu-law codec. This is done from the "RTP Stream Analysis" dialog by pressing the "Save payload..." button.
In addition, from Wireshark 0.99.4 onwards, it is possible to listen to RTP streams from within Wireshark. See VoIP_calls.
Other codec types
It is possible to save in rtpdump format for any codec (both audio and video) and use e.g. rtplay program from rtptools to replay the RTP stream towards JMF JMstudio, Apple QuickTime player and similar if they support the codec. But unfortunately there is no support for G.729 in those programs (maybe due to high license fees for G.729).
Here is a small example:
Install JMF (JMstudio is included) Download rtptools Open the RTP capture file with Wireshark
Select the proper UDP and force its decoding as RTP: Menu Analyze >> Decode As... RTP.
Menu Statistics(Wireshark 1.0) or Telephony >> RTP >> Show all streams. Select the one of your interest, and press button Save As... into a "rtpdump" formatted file. Start JMstudio
Menu File >> Open RTP Session and insert your local IP address (it didn't work with 127.0.0.1 for me) like this:
openrtpsession.png Press button "Open" - now JMstudio waits for the stream Open a terminal and type:
user@host$ rtpplay -T -f /path/to/your/captured.rtpdump 192.168.0.23/1234
You should now hear what you've captured. Note:JMstudio does not support every codec, but some commonly used for RTP (worked perfect for me to listen to a captured kphone-session using GSM as codec).
G.729
The ITU-T includes software routines to convert PCM audio (G.729 bitstream format) to and from PCM. If you buy such software package you can compile the decoder to extract the PCM audio from G.729 bitstream. This G.729AB bitstream is rather cumbersome (G.729AB packets are composed of several voice or silence chunks; in the ITU-T routines each chunk is identified by a leading sync pattern; further more, each bit in the payload must be coded as a 16-bit long word), so a modified version of rtpdump is required to extract G.729AB bitstream from the rtpdump file from Wireshark; download the sources of the version 1.18 of rtpdump, apply the patch rtpdump.c.1.18.patch, compile and follow these steps:
Open the RTP capture file with Wireshark
Select the proper UDP and force its decoding as RTP: Menu Analyze >> Decode As... RTP. Filter the G.729AB payload with display filter rtp.p_type==18.
Menu Statistics(Wireshark 1.0) or Telephony >> RTP >> Show all streams. Select the one with G.729 of your interest, and press button Save As... into a "rtpdump" formatted file. rtpdump -F itut -f file.rtpdump -o file.rtp decoder file.rtp file.pcm Import the file.pcm in Goldwave or Audacity (for example) as 16 bit signed mono, sampling ratio of 8000 Hz.
The flag "itut" for rtpdump is new to allow the decoding of rtpdump in ITU-T G.729AB format described above.
G.723.1
Once again the ITU-T includes software routines to convert between PCM audio and G.723.1 format. Fortunately the bitstream format expected by the ITU-T software routine "lbccodec" is simpler than in the case of G.729AB above, so the rtpdump program can be used as is with flag "payload":
Open the capture file with Wireshark.
Menu Analyze >> Decode As... RTP. Filter the G.723.1 payload with display filter rtp.p_type==8.
Menu Statistics(Wireshark 1.0) or Telephony >> RTP >> Show all streams. Select the one with G.723.1 of your interest, and press button Save As... into a "rtpdump" formatted file. rtpdump -F payload -f file.rtpdump -o file.rtp lbccodec -d file.rtp file.pcm Import the file.pcm in Goldwave as 16 bit signed mono, sampling ratio of 8000 Hz:
You can save an RTP stream in rtpdump format from the "RTP streams" dialog by selecting the stream and pressing the "Save As "button.
RTP stream analysis
If you want to analyze an RTP stream, there are two ways to select the one to analyze:
use the menu entry Statistics(Wireshark 1.0) or Telephony >> RTP >> Show All Streams... and select a stream in the upcoming "RTP Streams" dialog
select an RTP packet in the Packet List Pane and use Statistics(Wireshark 1.0) or Telephony >> RTP >> Stream Analysis...
... both ways will lead to the same "RTP Stream Analysis" dialog.
You can get the delay, jitter, bandwidth, etc. of that RTP stream. Also get general statistics like packet loss, maximum delay and sequence errors. Use the "Graph" button to see the jitter and difference between packets over time.
RTP_graph_analysis2.gif
How jitter is calculated
Wireshark calculates jitter according to RFC3550 (RTP):
If Si is the RTP timestamp from packet i, and Ri is the time of arrival in RTP timestamp units for packet i, then for two packets i and j, D may be expressed as
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
The interarrival jitter SHOULD be 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(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16
RTP timestamp: RTP timestamp is based on the sampling frequency of the codec, 8000 in most audio codecs and 90000 in most video codecs. As the sampling frequency must be known to correctly calculate jitter it is problematic to do jitter calculations for dynamic payload types as the codec and it's sampling frequency must be known which implies that the setup information for the session must be in the trace and the codec used must be known to the program(with the current implementation).
Developers with time to spend could change the current implementation to also record the sampling frequency in the SDP data and add that to the RTP conversation data and use that in the RTP analysis.
Example:
http://wiki.wireshark.org/SampleCaptures#head-6f6128a524888c86ee322aa7cbf0d7b7a8fdf353 file: aaa.pcap, stream: SSRC = 932629361
This is what we have in the packets and what we will use in the formula:
R0 = frame 624: frame.time = Jul 4, 2005 11:56:25.348411000
S0 = frame 624: rtp.timestamp = 1240
R1 = frame 625: frame.time = Jul 4, 2005 11:56:25.418358000
S1 = frame 625: rtp.timestamp = 1400
R2 = frame 626: frame.time = Jul 4, 2005 11:56:25.421891000
S2 = frame 626: rtp.timestamp = 1560
we also have rtp.p_type = ITU-T G.711 PCMA (8) and thus we know sampling clock is 8000Hz and thus the unit of rtp.timestamp is 1/8000 sec = 0.000125 sec .
Now the calculation:
frame 624:
J(0) = 0
frame 625:
D(0,1) = (R1 - R0) - (S1 - S0)
= [in seconds] (.418358000 sec - .348411000 sec) - (1400 * 0.000125 sec - 1240 * 0.000125 sec) = 0.049947
J(1) = J(0) + (|D(0,1)| - J(0))/16
= [in seconds] 0 + (|0.049947| - 0)/16 = 0.0031216875
frame 626:
D(1,2) = (R2 - R1) - (S2 - S1)
= [in seconds] (.421891000 sec - .418358000 sec) - (1560 * 0.000125 sec - 1400 * 0.000125 sec) = -0.016467
J(2) = J(1) + (|D(1,2)| - J(1))/16
= [in seconds] 0.0031216875 + (|-0.016467| - 0.0031216875)/16 = 0.00395576953125
How bandwidth (BW) is calculated
The BW column in RTP Streams and RTP Statistics dialogs shows the bandwidth at IP level for the given RTP stream. It is the sum of all octets, including IP and UDP headers (20+8 bytes), from all the packets of the given RTP stream over the last second.
For more details, see the function rtp_packet_analyse in file tap-rtp-common.c.