We record the answer SDP (not offer) to the metadata file, separeted by
newlines. It is after the PCAP file URL and before the timestamps. Maybe
we should be writing the rewritten SDP.
I refactored the handling of the "record-call" flag in the
"rtpengine_offer" and "rtpengine_answer" handler. We now set the
recording data structures in a function called `set_record_call`.
We also only handle "record-call" flags on OP_ANSWER for SDP answers.
In the rtpengine spool directory, when we create the "pcaps" and
"metadata" inner directories, we now give all users read and write
privileges to them, instead of just the owner and the group having those
permissions.
When we receive an offer or an answer, we will only turn recording on if
it contains the "record-call=yes" flag. Likewise, we only turn recording
off if it contains the "record-call=no" flag. If no flag is specified,
the call keeps its current recording status. It used to be the case that
not specifying "record-call=yes" would turn off call recording.
This fix is necessary to account for SDP renegotiation during
hold/unhold. If the call system sends over another offer during SDP
renegotiation to hold and then unhold, we don't want to change recording
behavior unless the call system specifically says so.
We want to be able to associate call files with a call without the
presence of identifying metadata within the metadata file. To accomplish
this, we prepend the call-id to the start of the pcap recording files
and the call metadata files.
Even though call-id is supposed to be unique, because of paranoia we
keep some of the random affix hex string, but we reduced it down to an
8-byte random value.
Also, some minor argument ordering and name refactoring for random
string generation functions.
We used to sometimes free the generic metadata (passed in through
rtpengine commands) before writing it to disk. Then we were writing
blank metadata to our metadata files. We fixed the ordering of
our `free` operations.
Now that all RTP streams for a call go to the same PCAP file, we don't need a
list of multiple PCAP files. We still separate it from the timestamps by an
extra newline.
This involved moving all code from fs.(c|h) to recording.(c|h).
We still spoof packets, so the UDP will look like all monologues are coming
over the same port and will probably look like they are all one stream if
you look at the PCAP file.
Command line option is "--recording-dir".
Renamed inner recording spool "recordings" to "pcaps".
This is to avoid name sharing conflicts with the "--recording-dir" command
line option, which specifies the recordings spool directory, and the
"$RECORDING_DIR/recordings" inner directory. Changing the inner directory
name to "pcaps" removes this name collision.
In the process, I changed the function names in fs.h to be consistent with
other functions. The names are structure like "$OBJECT_$VERB".
Fixes and changes:
- Only create the metadata file if the call is being recorded.
- Only write to the metadata file if we actually created it (NULL check).
- Make sure we have metadata before putting it on the call object
- Correctly overwrite recording metadata without leaking memory
- Set the no kernalization flag per call instead of for *every* packet.
- Logging cleanup.
File system code is now in fs.{h|c}. This includes:
- spool directory setup
- metadata file management
- pcap file creation and writing
Random hex string generation is now in str.h.
We create a metadata file for each call. The metadata files will all end up
in a spool directory for the rtpengine.
Each in-progress file has the format: "rtpengine-meta-$RANDHEX.tmp" and
goes in /tmp/. When a call finishes, it is moved to the spool directory
in sub-directory /var/spool/rtpengine/metadata/ and we change the file
extension to ".txt".
The metadata file contains references to all PCAP recording files associated
with a call, and it includes generic metadata at the tail of the file.
One absolute path for a PCAP file per line, followed by two blank lines,
followed by the metadata passed in to the rtpengine through an external
command.
RTP Engine checks for the spool directory "/var/spool/rtpengine" on startup.
If it's not there, it fails. If it's there, it sets up "metadata" and
"recordings" inner directories. This is where RTP Engine will write call
metadata files and PCAP files.
Creating a random filename with a prefix and a suffix is now done through a
generic function. We use this to create pcap recording files in the /tmp/
directory, and will soon use it to create metadata files.
RTP Engine creates PCAP files for recorded calls on offer answer instead
of initial offer.
We make up bogus values for the nonessential parts of the PCAP, UDP, and
IP headers. We might be able to pull these from other parts of the RTP
Engine, but that information was unnecessary for recording calls so they
can be recorded to audio files.
If you change the packet headers, be really careful about byte order and
datatype size!
Pass in "record-call" flag over `rtpengine_offer` or `rtpengine_answer`
message. RTP Engine tracks files used to record pcaps and send them back
in the response message.
Pipes call audio (unencrypted from both ends) to recording files.
Sets up file descriptors for local files to dump RTP recordings.
A file and a file descriptor per monologue in a call.
Recorded streams will be running in user daemon mode, not in kernel mode.
This removes first 12 octets from packet to record just the rtp.
fix typo and error:
./rtpengine.init: line 111: syntax error in conditional expression
./rtpengine.init: line 111: syntax error near `-a'
./rtpengine.init: line 111: ` if [[ -n "$REDIS" -a -n "$REDIS_DB" ]]'
Dylan Mikus
Eric Green
Richard Fuchs
Sergey Lavrov
Stefan Mititelu
Pawel Kuzak