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
* 0 will allow 0 sessions (e.g. can be used for draining rtpengine)
* -1 will disable the feature and will be treated the same way as if
MAX_SESSIONS variable has not been set via configuration file
(or has been set to -1 in configuration file)
* < -1 will not be taken into consideration
* add check for minint range also
RTPengine starts with 1048575 (1<<20 - 1) maximum open files limit.
Make the maximum number of open files configurable using
"rtpengine-ctl set max-open-files 'open_files_num'" command.
Update utils script.
Don't ignore incoming DTLS packets after DTLS-SRTP has completed and
make sure the DTLS send queue is empties as much as possible
Change-Id: I0760c844835640385f2322767993f7eaa082bd86
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.
Some WebRTC clients include a=mid attributes even when BUNDLE is not in
used. This can cause problems in an answer if the offer originally used
a=mid too, as a mismatch in mid values may upset the client.
Closes#157
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.
use via-branches to predict different destinations for branched SDP
offers without knowing the respective to-tag ahead of time.
Squashed commit of the following:
commit 0e81dc98285d81cf8014034a698bc57e6af14c98
Author: Richard Fuchs <rfuchs@sipwise.com>
Date: Thu May 21 11:06:15 2015 -0400
fix segfault due to missing reverse tagging
commit cd7a26314b3406faac910897d96cd4d7586fc567
Author: Richard Fuchs <rfuchs@sipwise.com>
Date: Thu May 21 08:57:42 2015 -0400
support branched offer with previously unseen to-tag
commit 77da616dd2be230b03cc480ad6dd810b2742f5aa
Author: Richard Fuchs <rfuchs@sipwise.com>
Date: Wed Apr 29 11:15:37 2015 -0400
implement via-branch handling