The redis onekey concepts is introduced to reduce traffic to redis
and redis notification traffic.
It modifies the current structure for one call in redis, which are
multiple keys with pre- and postfixes and the callid in between to
one key with the structure "json-<callid>". The value is a json
formatted string with the previous multi-key identifiers in it.
instead of outright rejecting local endpoints advertised by remote
clients (to allow for deliberately daisy chaining packet streams), we
flag them for checking against actual packet loops as we did before
Change-Id: I5652e86e12f3c1c5053ea70b01e8d128ebf47751
fixes#65
this also obsoletes the old loop detection
Change-Id: I850d81500c45828af2c4d50d80278ec2d599c2a0
(cherry picked from commit 3254278cfd55167fb881cc665328744183773728)
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.
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".
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.
- add --subscribe_keyspace list config parameter.
- don't delete foreign calls by timers
- fix synchronization of foreign calls (use a separate redis_notify database)
- fix statistics for control channel calls.
- fix deletion of foreign calls upon del notifications
- update rtpengine-ctl tool
Removes the explicit redis-read-db configuration and reduces the option
to one redis DB and one redis write DB. If only the redis DB is
configured, then it will be used for all operations. If both are
configured, then the redis DB will be used for reading and the write DB
will be used for writing (updates).
Change-Id: I8d5a32c53c9416b514c98d69c3afe7c547e530ad
The session limit is only for calls an rtpengine is responsible for.
Foreign calls (coming in via redis notification) are not counted as
long as the rtpengine is not responsible for those calls.
At least that means that the limit may exceed if the calls the rtpengine
is responsible for plus the former foreign calls are greater than the limit.
This will happen suddenly when the rtpengine becomes responsible for the
foreign calls.
supports aliasing a local interface multiple times with the same local
address for different advertised addresses
closes#216
Change-Id: I6f98d1a17290b0bb1831e48ad89fc61d8b2d7914
Thoughts on that topic so far:
There's one thing to keep also in mind. What do we do if the call
changes (streams) and the backup node is notified ? Currently we only
know (by subscribing to the 'notifier-' prefix that in fact it has
changed, but we don't know what has changed in detail. Subscribing to
everything would lead to the problem that we have to take care about
synchronising the the new streams with the old ones. Without having a
look at the code that might be a lot of effort and ... I guess that's
why richard likes to ... have clean states of the calls. Synchronizing
is always a mess. Easier to delete and setup new.
I thought about the following solution for makes things more abstract
and easier to understand:
1. Whenever that call on a backup node (foreign call) has seen a packet
(also timers are started then), we do not process any notification by a
redis notification for this call (caus' the RTP-IP has already been
switched). More precise and abstract that means: If a node has taken
over the responsibility for that call (by having seen a packet), it
assumes that notifications from the former node to be dropped. The call
will be deleted when either the timer fires or (for other companies) the
control channel address has also been switched and via that channel the
call is deleted.
2. If a call has not seen a packet (inactive call on the backup node,
seen as not responsible for that call but could become so), we accept
all commands for that call on the backup node in the same way as on the
original node. That means also deletions in-between and so on. I mean if
the original node does it, why not accepting to do the same way on the
backup node ?
Currently, every rtpengine will subscribe to redis-keyspace notification
so it will receive a notification when an call is inserted. If the call
is not already handeled by the rtpengine, the call will be restored.
The reason for this is to have in-place redundancy. Imagine you have
multiple rtpengines running, eachone will have all calls of the others.
When one rtpengine fails somehow, infrastructure guys use BGP in order to
'move' the IP address from one rtpengine to another. Thisone can handle
the new calls instantly since they're already recovered by
redis-notification feature.
Next step is internally identify those calls in order to prevent some
timers to delete the calls where no RTP flows. Second will be
something we call 'partitioning'. It means that the subscription
to a redis notify will only be for the keyspace a dedicated rtpengine
writes to. This leads to the point that you can make redundancy groups
(partitions) of the rtpengines.
This brings master up to date with branch `rfuchs/socket-rework` at
commit `b1bcc096b7`. The branches have diverged too much for a proper
merge, so this is a manual (squashed) merge.
The old master before this merge can be found in branch
`old-master-before-socket-rework` (commit `82199216b2`).
This is a complete rewrite of all socket handling routines. The most
important functional change is that sockets aren't indiscriminately
bound to INADDR_ANY (or rather in6addr_any), but instead are always
bound to their respective local interface address and with the correct
address family.
Side effects of this are that in multi-homed environments, multiple
sockets must be opened (one per interface address and family) which must
be taken into account when considering RLIMIT_NOFILE values. As a
benefit, this change allows rtpengine to utilize the full UDP port space
per interface address, instead of just one port space per machine.
The socket abstraction also makes it possible to support RTP over TCP in
the future.
Change-Id: If6cf4f42136229490186d2d2482fb4fc140c2b53
This enables switching over the endpoint of a dialogue to a new client
with potentially different capabilities
Change-Id: I973b3c5d004014cc73e6ebc3e87d03c742bc1951
(cherry picked from commit 69b7586aa4)
(cherry picked from commit 93332f0f6e)
Avoid buffer overflows.
Also make cdrbuffend -= 1; append spaces to the TRUNCATED message because
syslog trims the output to 8205 chars on a line for big log buffers.
The payload types are not saved and retrieved from redis. Used a hash to
store the payload types in the form (0, payload_value0), (1, payload_value1)
for every media.
Claudiu Boriga
Richard Fuchs
Michael Prokop
Frederic-Philippe Metz
Lucian Balaceanu
Pawel Kuzak
Dylan Mikus
Eric Green
Stefan Mititelu
Lucian Balaceanu