Depending on the build environment, $M might refer to a subdirectory of
the main source tree (i.e. debian directory is in $M/../debian) or the
main directory of the source tree (debian is at $M/debian). Use a shell
test to detect the correct file.
Also take git revision into account as additional info, same as the
daemon build system does.
Change-Id: Ib82ff2f9b1a1b0c94697fd91d5b9e9c9bb8e61f2
Avoid segfault that happened when ps->component=0 (only when redis involved).
If redis involved, ps structure is initially 0'ed before restoring. Currently
the ps->component is not restored and leads to the above segfault.
Noticed during lintian reviews + test builds
of ngcp-rtpengine-kernel, STR:
* Install ngcp-rtpengine-kernel-source + module-assistant
* m-a build ngcp-rtpengine-kernel fails with:
| tail: cannot open ‘/usr/src/modules/ngcp-rtpengine/../debian/changelog’ for reading: No such file or directory
| dpkg-parsechangelog: error: tail of /usr/src/modules/ngcp-rtpengine/../debian/changelog gave error exit status 1
| Building modules, stage 2.
| MODPOST 1 modules
| tail: cannot open ‘/usr/src/modules/ngcp-rtpengine/../debian/changelog’ for reading: No such file or directory
Fix conflicts:
| dh_gencontrol -- -v4.3.0.0+0~mr4.3.0.0+0~20160223155548.661+jessie~1.gbp6d1932+3.16.7-ckt20-1+deb8u3
| dpkg-gencontrol: error: source package has two conflicting values - ngcp-rtpengine-kernel and ngcp-rtpengine
| dh_gencontrol: dpkg-gencontrol -pngcp-rtpengine-kernel-modules-3.16.0-4-amd64 -ldebian/changelog -Tdebian/ngcp-rtpengine-kernel-modules-3.16.0-4-amd64.substvars -Pdebian/ngcp-rtpengine-kernel-modules-3.16.0-4-amd64 -v4.3.0.0+0~mr4.3.0.0+0~20160223155548.661+jessie~1.gbp6d1932+3.16.7-ckt20-1+deb8u3 returned exit code 255
| debian/rules:58: recipe for target 'binary-modules' failed
While at it Bump Standards-Version for ngcp-rtpengine-kernel
to 3.9.7 (no further changes) and fix package description.
Change-Id: Iaf7326f55cd3919afdb140d8e7acb5d3ff87b7d9
- 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
Avoid segfault that happened when ps->component=0 (only when redis involved).
If redis involved, ps structure is initially 0'ed before restoring. Currently
the ps->component is not restored and leads to the above segfault.
Noticed during lintian reviews + test builds
of ngcp-rtpengine-kernel, STR:
* Install ngcp-rtpengine-kernel-source + module-assistant
* m-a build ngcp-rtpengine-kernel fails with:
| tail: cannot open ‘/usr/src/modules/ngcp-rtpengine/../debian/changelog’ for reading: No such file or directory
| dpkg-parsechangelog: error: tail of /usr/src/modules/ngcp-rtpengine/../debian/changelog gave error exit status 1
| Building modules, stage 2.
| MODPOST 1 modules
| tail: cannot open ‘/usr/src/modules/ngcp-rtpengine/../debian/changelog’ for reading: No such file or directory
Fix conflicts:
| dh_gencontrol -- -v4.3.0.0+0~mr4.3.0.0+0~20160223155548.661+jessie~1.gbp6d1932+3.16.7-ckt20-1+deb8u3
| dpkg-gencontrol: error: source package has two conflicting values - ngcp-rtpengine-kernel and ngcp-rtpengine
| dh_gencontrol: dpkg-gencontrol -pngcp-rtpengine-kernel-modules-3.16.0-4-amd64 -ldebian/changelog -Tdebian/ngcp-rtpengine-kernel-modules-3.16.0-4-amd64.substvars -Pdebian/ngcp-rtpengine-kernel-modules-3.16.0-4-amd64 -v4.3.0.0+0~mr4.3.0.0+0~20160223155548.661+jessie~1.gbp6d1932+3.16.7-ckt20-1+deb8u3 returned exit code 255
| debian/rules:58: recipe for target 'binary-modules' failed
While at it Bump Standards-Version for ngcp-rtpengine-kernel
to 3.9.7 (no further changes) and fix package description.
Change-Id: Iaf7326f55cd3919afdb140d8e7acb5d3ff87b7d9
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
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 ?
Richard Fuchs
Stefan Mititelu
Michael Prokop
Frederic-Philippe Metz
Pawel Kuzak