FreeCalypso > hg > gsm-codec-lib
view doc/RTP-analysis @ 183:452c1d5a6268
libgsmefr BFI w/o data: emit zero output after decoder reset
In real-life usage, each EFR decoder session will most likely begin
with lots of BFI frames before the first real frame arrives. However,
because the spec-defined home state of the decoder is speech rather
than CN, our regular logic for BFI w/o data would have to feed
pseudorandom noise to the decoder (in the "fixed codebook excitation
pulses" part), which is silly to do at the beginning of the decoder
session right out of reset. Therefore, let's check reset_flag_old,
and if we are still in the reset state, simply emit zero output.
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Tue, 03 Jan 2023 00:12:18 +0000 |
parents | 9fb22fa4d373 |
children |
line wrap: on
line source
The present package includes a number of utilities for analyzing RTP streams that have been captured with tcpdump or equivalent tools in pcap format. In order to use any of these utilities, you need to have a pcap file (obviously), and you need to identify the RTP stream to be analyzed or extracted by either source or destination IP:port. All tools begin by applying a filter, considering only those packets that are UDP in IPv4 (no IPv6 support currently), and only those that match the specified source or destination IP:port. Every matched packet is checked for a valid RTP header, and then the actual RTP stream analysis or extraction takes place, depending on the specific tool: rtp-cont-check This program checks the selected RTP stream for continuity. It verifies that every matched packet has the same SSRC, that the sequence number always increments by 1 from each individual packet to the next, and that the RTP header timestamp always increments by 160 units. (The assumption is that the application at hand is in the traditional telephony domain, with a sampling rate of 8000 samples/s and 20 ms packetization for RTP.) This tool also looks at the capture time deltas between successive packets and reports the observed minimum and maximum; by seeing min and max delta-T, a developer can easily notice timing aberrations that aren't caught by RTP header sequence number and timestamp checks. rtp-g711-extr This program focuses on a single selected RTP stream like the others, enforces its continuity just like rtp-cont-check, and then further enforces that every RTP packet be a 160-byte payload, presumed to be either PCMU or PCMA. (The payload type number is NOT considered, only the payload length.) The selected G.711 RTP stream is then extracted and written into a raw binary file. rtp-gsmfr-extr This program focuses on a single selected RTP stream like the others, enforces its continuity just like rtp-cont-check, but then further enforces that every RTP packet be one of these 3 possibilities: a GSM FR1 codec frame, a GSM EFR codec frame or a Themyscira BFI marker as defined in the RTP-BFI-extension document. (The payload type number is NOT considered, only the payload length and the characteristic signature of each of the 3 allowed possibilities.) The selected RTP stream is then extracted and written into a gsmx file (see Binary-file-format), which can then be analyzed with gsmrec-dump or decoded to playable WAV with gsmfr-decode or gsmefr-decode. rtp-jitter-view This program analyzes a single selected RTP stream just like rtp-cont-check, but instead of reporting minimum and maximum time deltas for the entire stream, it prints the individual capture time delta between every successive pair of packets.