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.