Osmocom E1/T1 span recorder https://osmocom.org/projects/osmo-e1-recorder
Go to file
Harald Welte 456135a605 e1_recorder: Fix potential null-dereference
Fixes: CID#307523: Dereference null return value (NULL_RETURNS)
Change-Id: I481f0695f971f5cd2e77b8c9c62d423a70e0840d
2023-07-18 14:40:30 +02:00
contrib Support RPM building via contrib/osmo-e1-recorder.spec.in 2022-11-06 12:36:05 +01:00
doc convert build system to autotools 2019-11-24 18:42:29 +01:00
src e1_recorder: Fix potential null-dereference 2023-07-18 14:40:30 +02:00
tests tests: adjust slot numbers 2021-05-18 12:05:16 +02:00
.gitignore update .gitignore 2019-11-24 18:42:29 +01:00
.gitreview Add git-review config 2022-12-23 11:16:30 +00:00
Makefile.am Support RPM building via contrib/osmo-e1-recorder.spec.in 2022-11-06 12:36:05 +01:00
README.md README.md: Fix lots of typos + formatting in markdown 2022-11-06 10:36:36 +01:00
configure.ac configure.ac: migrate from python2 to python3 2023-07-15 00:58:55 +07:00
git-version-gen convert build system to autotools 2019-11-24 18:42:29 +01:00
osmoappdesc.py configure.ac: migrate from python2 to python3 2023-07-15 00:58:55 +07:00

README.md

Osmocom E1 recorder

(C) 2016 by Harald Welte laforge@gnumonks.org

The idea of this program is to be able to build a "poor mans E1/T1 recorder" purposes of data analysis, without any special equipment.

This approach is more risky than a purely passive, hardware based approach as that of the Osmocom e1-tracer released at https://osmocom.org/projects/e1-t1-adapter/wiki/E1_tracer

If you can, it is strongly recommended to use the purely passive, high-impedance tap approach of e1-tracer and not the poor-man's software proxy approach presented in osmo-e1-recorder.

Setup

To do so, two E1 cards are used as some kind of proxy for the E1 communication. Recording of a single E1 link always requires two E1 interface cards, one for each direction.

Recording can be performed either

  • passively, using a E1 Tap adapter
  • as a proxy / man-in-the-middle

All timeslots will be opened in "raw" mode, making sure the recording will work whether or not there is HDLC-based signalling (MTP or LAPD), PCM voice, TRAU frames or anything else on the line.

Recording will be done on a per-timeslot basis, dumping the raw bytes read for this timeslot into a file.

New files are started regularly, after reaching a pre-determined file size limit. File names contain RTC time stamping and timeslot number.

Later possible extensions could include automatic detection of the payload and a more intelligent storage format (e.g. in case of HDLC based signalling).