In case of an offer with a via-branch followed by a delete without a
via-branch (cancelled call), the call erroneously remains open after
deleting one half of the call. The reason is that un-answered branches
do not appear in the `other_tags` list and so are left out from being
checked.
Change-Id: Ib008f32ef5ee06a7ca997c900c9a3adc85b0f10d
This can presumably happen when an encoder gets re-initialised due to an
SSRC table overflow, or when a passthrough encoder (e.g. G.729) returns
no data.
Possibly fixes#915
Change-Id: Ib351054b99754f46d0a8fb2d49629ce7c48dc964
(cherry picked from commit 11e2893c0e)
The hash table cannot be used for storage any more as entries can be
removed on demand (64e56d7) but can be cached in packet->handler at the
same time.
Possibly fixes#915
Change-Id: Ic74703b1a57294bfd704b6cddcd666d6063f510a
(cherry picked from commit d3992101bd)
fix cleanup being skipped on redis slaves
fixes an SDES related Redis mem leak
adds a hash for the ports free list to avoid duplicate entries
fixes#898
Change-Id: I34aad67290ff5ef8824142682aac03cb600d0ecb
(cherry picked from commit c70b3f6369)
A client can potentially change the codec used for a RTP payload type
number, so we must confirm that an existing handler matches the codec
from the SDP.
fixes#903
Change-Id: Id9ae379425359f776883d6ace7fdb44ad651b37e
(cherry picked from commit 64e56d774b)
Untagged branches (only known by via-branch) don't appear in the `tags`
hash and don't have any `other_tags`. The logic to determine whether the
call is completely finished therefore must take these into account
separately.
We take care to remove destroyed monologues from the `viabranches` hash
to keep the count up to date, and determine whether a call is terminated
when there is no more than 1 tagged monologue left and no untagged
monologues.
Closes#875
Change-Id: I6b9618d598f4a95970cd2a452f06574423932b09
(cherry picked from commit e0dd6747ea)
required to distinguish between 20-ms and 30-ms modes, both for encoding
and decoding
add support for the iLBC mode= format parameter and dynamic mode
switching
closes#854
Change-Id: Icb6f0ec80df86d27681c689c168b24f163a2db06
(cherry picked from commit 228d822a71)
If B accepts a crypto suite that was not listed as the first, in order
to support SRTP passthrough, we correctly answer to A with only that one
crypto suite. But we must also remove all other crypto suites from our
list of supported crypto suites internally, because we use the first one
to init our crypto contexts.
fixes#829
Change-Id: Id07343d7b24648208e3a4b4e0b246949dce0385e
(cherry picked from commit 3466700149)
There's no point in starting the notification thread and another Redis
connection if there are no keyspaces to subscribe to
Change-Id: I2a9ef3b7764219b6ca08ebbe81461efd45b3e9de
(cherry picked from commit bfc9799c7e)
We need to set the redis context to NULL after freeing it, otherwise
other code will try to free it again, which will make the program
abort when exiting.
Change-Id: Id634075344351eb1c924c59739b72bbf57de3c89
(cherry picked from commit 781b275295)
When both logging and sending the DTMF event further, the json buffer
was released/freed _before_ being sent on the network, resulting in a
0-length UDP packet. On the other hand, if only UDP sending was used
(without logging), a leak was happening. This commit fixes both issues.
If `strict source` is set, we can now also kernelise RTCP ports. This
will engage the kernel module's source address checking. If the check
fails, the packet is discarded. Otherwise it's passed to user space
as usual.
Change-Id: Ieedf39fba2263045b0f1faafa7f5826a27b5a115
Move the RTCP_MUX_OVERRIDE flag to the opposite side of the dialogue to
preserve options given during a branched call.
closes#793
Change-Id: I0bd7621ba22fbfe4f41d115ec2e5dab65283ae01
If multiple codecs are encoding to the same destination codec, make them
all use the same encoder context
Change-Id: Iaf9b248f9fd2016fef2b576d24d3fba557d7c1f5
In case of out-of-sequence queued-up packets, the codec handler in use
was the one from the last packet delivered to the sequencer, which might
be a different one from the one needed for each packet coming out of the
sequencer.
Change-Id: Id7fb21328f7d181244a9be2ae5ff13cb6bad31b7
Every packet_stream gets a send_timer allocated, but the teardown
routine skips the refcount decrease for fallback RTCP streams (when
rtcp-mux is in use), resulting in mem leak
fixes#753
Change-Id: Ib3a4ef8a81135918f08e28e127e4bb557b8ea05d