Updating, freeing, and writing the recording metadata is now
threadsafe. This is in regards to the metadata that we receive from
the `rtpengine_offer` or `rtpengine_answer` commands, not the
`meta_fp` file.
We can simply use the `call->master_lock` variable for protecting
updates to the recording metadata. We had to move the metadata
handling code in call_interfaces.c up into the master_lock guarded
section. The code in "recording.c:meta_finish_file" is called with
master_lock protection already.
- The packet counter was accidentally a pointer, resulting in it
incrementing by 8 instead of 1. That is fixed.
- Use proper formatting macro for uint64_t printing.
- Start PCAP packet indexing at 1 since that is what Wireshark does.
In the call recording metadata file, start and end timestamps for the
call are now "key: value" formatted so you can tell what they are just
by reading the metadata file.
We write out what RTP packet number the SDP came before. When we receive
an SDP offer or answer, we write out the RTP packet number that the SDP
preceeded. This will let us split the RTP recording PCAP around SDP
renegotiation for things like hold/unhold.
Also write out whether the SDP was an offer or an answer.
When we write out the start time of a call for the recording metadata,
we used to get the timestamp from the given `call_monologue.started`
member. This value changes after each SDP renegotiation. Now, we use the
`call.created` member.
I changed metadata file permissions to 664.
I made some non-void functions properly return non-void values. This
does not change any functionality. Just quiets a few compiler warnings.
We want to be able to match up the source and target <IP>:<PORT> with
the IP and port info sent in SDP. I adjusted the source and target
<IP>:<PORT> we write to the IP and UDP headers in the PCAP file.
I added the offer SDP (in addition to the already written answer SDP)
to the metadata file.
As a consequence of writing out the offer SDP, we will have empty PCAP
files and associated metadata files for calls that are never answered.
squash! Fixes to match PCAP packets with SDP
Added comments detailing the types of endpoint IP/port values we can
use.
We write the call-id out as part of the filename for pcap and metadata
files for recorded calls. We don't want troublesome characters to be in
the filename, so we urlencode the filenames.
In the recording metadata files, we now separate each logical section of
metadata by two blank lines. So, it goes:
1. the PCAP file URL
2. two blank lines
3. all answer SDP, each separated by one blank line
4. two blank lines
5. start timestamp
6. end timestamp (no blank line in between)
7. the rest of the file is unstructured metadata (any number of lines)
We had initialization code for recording scattered through
"call_interfaces.c", "call.c", and "recording.c". I moved more of the
actual code into functions within recording.c under the parent function
`detect_setup_recording`. We call this function from "call_interfaces.c".
I moved the disjointed bit of PCAP initialization to occur right below
where we toggle recording on or off.
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.
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".
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.
Claudiu Boriga
Richard Fuchs
Kristian Høgh
Dylan Mikus
Eric Green