iptables-dev is only available until Debian/buster and no longer exists in
Debian/bullseye (current testing) nor unstable/sid:
| builddeps:. : Depends: iptables-dev (>= 1.4) but it is not installable
Even in Debian/buster iptables-dev is already a transitional/dummy package.
Support iptables-dev as alternative Build-Dependency, just in case
someone is building the package against a system where libxtables-dev
doesn't exist yet.
Change-Id: I28c4c81ac474c646d80a0146baa2446dde7073c3
rtpengine-ctl uses Config::Tiny for reading the config file.
This commit adds the dependency to the utils package.
Change-Id: Iae0892fe9c8d30435eecc513cf538122b2fbe2c7
- Stop copying debian/compat into the kernel source packages.
- Use dh_installsystemd instead of deprecated dh_systemd_*.
- Disable dwz as it cannot cope with some of the plugins generated.
Change-Id: Ibdc92e94955ef3c5d89b24fc341474236c49b986
To avoid repeated strcmp()s and make use of switch()'s optimised binary
lookup, we employ a second build step that preprocesses certain .c files
and uses gperf to substitute pseudomacros with their respective constant
hash value.
Change-Id: Id89c4728a0fc7aa911691d4dd1ba8e7b3916a983
Debian relies on the output of lsb-release in dkms, while
it doesn't strictly depend on it (it's just a Recommends).
We reported the bug towards dkms in Debian as
https://bugs.debian.org/896814
The best we can do until the underlying bug in dkms is fixed
is to depend on the lsb-release package in our ngcp-rtpengine-kernel-dkms
itself.
Change-Id: I2946b971ff463cec8f6e198b4a618ed0e056534c
Thanks: Richard Fuchs for debugging the issue
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.
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!
No further changes required to update to Debian Policy 3.9.7[.0]
While at it also execute 'wrap-and-sort -a' on debian/.
Change-Id: I7388491a5c0b2f4ea732db767bddfd67f9d21d3b
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.
On upgrades from 2.8 LTS we have to install ngcp-rtpengine-kernl-dkms package
before the upgrade in order to get dkms to work. No need to upgrade the new
version of ngcp-system-tools too
Change-Id: I36fbfdffc5ca1e283ba0e8d5a42a96a72fbf324e
In order to be able to run NGCP inside a container adding the use
of our ngcp-system-tools helper to check the environment.
Merged changes from templates
Richard Fuchs
Guillem Jover
Michael Prokop
Sebastian Damm
Victor Seva
Frederic-Philippe Metz
Pawel Kuzak
Dylan Mikus
Stefan Mititelu