comparison doc/RTP-analysis @ 173:aaa0380f9958

doc/RTP-analysis: document new tools
author Mychaela Falconia <falcon@freecalypso.org>
date Tue, 27 Dec 2022 00:00:57 +0000
parents 8eb0e7a39409
children 9fb22fa4d373
comparison
equal deleted inserted replaced
172:693a0958a303 173:aaa0380f9958
1 The present package includes a utility named rtp-gsmfr-extr; this utility 1 The present package includes a number of utilities for analyzing RTP streams
2 extracts a single RTP stream in either FR1 or EFR codec format from a pcap file, 2 that have been captured with tcpdump or equivalent tools in pcap format. In
3 presumably captured with tcpdump on an IP network serving either an IP-based BTS 3 order to use any of these utilities, you need to have a pcap file (obviously),
4 or a gateway from an E1-based BTS to RTP - the intent is to extract a GSM call 4 and you need to identify the RTP stream to be analyzed or extracted by either
5 uplink that has been rendered into an RTP stream by a BTS. The RTP stream being 5 source or destination IP:port. All tools begin by applying a filter,
6 extracted must be fully continuous without any gaps, using Themyscira 6 considering only those packets that are UDP in IPv4 (no IPv6 support currently),
7 RTP-BFI-extension BFI marker packets in those 20 ms windows where no good 7 and only those that match the specified source or destination IP:port. Every
8 traffic frame has been received. rtp-gsmfr-extr verifies continuity of the RTP 8 matched packet is checked for a valid RTP header, and then the actual RTP stream
9 stream being extracted: any detected discontinuity (either a sequence number 9 analysis or extraction takes place, depending on the specific tool:
10 jump indicating packet loss or a timestamp jump indicating an intentional gap
11 generated at the source) will be reported, and the extraction will stop there.
12 10
13 To run rtp-gsmfr-extr, you need to have a pcap file (obviously), and you need to 11 rtp-cont-check This program checks the selected RTP stream for continuity. It
14 identify the RTP stream to be extracted by either source or destination IP:port. 12 verifies that every matched packet has the same SSRC, that the
15 rtp-gsmfr-extr will look at every UDP packet that matches this src-IP-port or 13 sequence number always increments by 1 from each individual
16 dest-IP-port filter, and then check for valid RTP, verify the expected increment 14 packet to the next, and that the RTP header timestamp always
17 in sequence and timestamp numbers, check for either FR1 or EFR payload (or a 15 increments by 160 units. (The assumption is that the
18 Themyscira BFI marker for FR & EFR), and finally write the extracted frame 16 application at hand is in the traditional telephony domain,
19 stream to a gsmx file. This gsmx output can then be analyzed with gsmrec-dump, 17 with a sampling rate of 8000 samples/s and 20 ms packetization
20 or decoded to playable WAV with gsmfr-decode or gsmefr-decode. 18 for RTP.) This tool also looks at the capture time deltas
19 between successive packets and reports the observed minimum and
20 maximum; by seeing min and max delta-T, a developer can easily
21 notice timing aberrations that aren't caught by RTP header
22 sequence number and timestamp checks.
23
24 rtp-gsmfr-extr This program focuses on a single selected RTP stream like the
25 others, enforces its continuity just like rtp-cont-check, but
26 then further enforces that every RTP packet be one of these 3
27 possibilities: a GSM FR1 codec frame, a GSM EFR codec frame or
28 a Themyscira BFI marker as defined in the RTP-BFI-extension
29 document. (The payload type number is NOT considered, only the
30 payload length and the characteristic signature of each of the
31 3 allowed possibilities.) The selected RTP stream is then
32 extracted and written into a gsmx file (see Binary-file-format),
33 which can then be analyzed with gsmrec-dump or decoded to
34 playable WAV with gsmfr-decode or gsmefr-decode.
35
36 rtp-jitter-view This program analyzes a single selected RTP stream just like
37 rtp-cont-check, but instead of reporting minimum and maximum
38 time deltas for the entire stream, it prints the individual
39 capture time delta between every successive pair of packets.