This fix a potential crash into waitForData where the channel is deleted
after the check and before locking. Also notify when deleting. Also
add isDestroying on channel to avoid to wait indefinitely on destroyed channel
GitLab: #549
Change-Id: Ib37c4bab31def4ca6f594fc1338a018138217765
If the scheduler's has a job that owns the last reference to the scheduler
itself, then the thread will try to join itself in the destructor of the
scheduler, resulting in `std::terminate()`. Thus, detach the thread if the
scheduler is freed from its thread, because nobody is supposed to have a
reference to the thread.
This introduces a read after free of `running_`. By making it a shared value,
the thread can keep a reference after destruction of the scheduler.
Gitlab: #545
Change-Id: I0118c99a5718d302f916099e24606add444546d8
There are mismatches between versions of lcov/gcov/gcc on Ubuntu 18.04. Thus,
using Ubuntu 20.04.
GitLab: #1187
Change-Id: I8809cd944f90c94092241368405eac4cd5c51e8f
Due to 6f81927c70 PJSIP_SC_BUSY_HERE is sent
instead of PJSIP_SC_DECLINE. This means that the signal received must be
taken into account for closing other subcalls on a multi-device context.
Change-Id: Iad36d2a5b07eb75d89a31a5476c6aa5ddeec2ced
GitLab: #547
2 seconds is too short on some system to spawn 1024 threads. Increase this by a
second. This is highly system dependent and we might want to change the logic
of the test instead.
Gitlab: #545
Change-Id: Id939ad4809e47a2cdce19885387464289110e137
If not called, other threads might read memories freed by the exit handlers of
the main thread, resulting in a race condition that can cause a segmentation
fault.
Gitlab: #545
Change-Id: I29ec4c1ffee96b6a083e36f31cd738daf622315d
Detecting that a socket is down via a keep alive can take time, moreover
if a relay is used, because the keep alive can continue to work even if the
connection is half closed.
In this patch, we add a mechanism where a beacon is sent over the multiplexed
socket to know if the peer can answer. This message can be used to detect
if a socket is usable and is sent whenever the user starts a call or that
a connectivityChanged() occurs.
Moreover, the multiplexedsocket can now sends a version to enable features
and if a bad packet on the control socket comes, the socket is not stopped.
GitLab: #542
Change-Id: Ia66d8d7f9b66bba02927f4ea41c21ef27089bceb
If `duration_start_` is `time_point::min`, then when calculating the call's
duration, there's an signed integer overflow which result in an enormous time
duration.
Signed-off-by: Olivier Dion <olivier.dion@savoirfairelinux.com>
Change-Id: I3ad119ab0f79ef8e9c537d1879d628a29ceed4d7
Wrong constructor was used, resulting in buffer overflows. Although it's benign
because of read only of a data section, ASAN doesn't like it at all.
Also added missing newline at end of file.
Signed-off-by: Olivier Dion <olivier.dion@savoirfairelinux.com>
Change-Id: I15553855ea368ec00456db80abb065599adc0d49
Check AudioFrame pointer before using it to avoid segfault.
AudioFrame instances with null inner pointer was observed at
least with unit tests.
Gitlab: #541
Change-Id: I1e459590b9c247be3b6137bf8645f604ecbbe45c
Currently, an incoming call is always assumed to have either audio
and video media or only audio media.
This assumption was removed and the incoming call are reported with
the list of included media with some of their attributes as found in
the call invite (SDP). This will allow to process calls with an
arbitrary number of media.
It will also allow to add new media to a call by requesting a media
change using a SIP re-invite (with new SDP). For instance, add video
to an audio-only call. The peer will receive the new offer and may
choose to accept or not the new media.
Not all media change requests require validation from the user/client.
Meaning that for instance, if a new SDP (media change request) is
received to notify that the peer muted it's audio, the media change
request can be processed without requiring validation from the
user/client.
Gitlab: #445
Change-Id: Ibc2b2501a3ec7e2c22f4e9d47cec3eda3dd43fef
storeActiveIpAddress is done for each connectivityChange(), but
this logic is incorrect, because the ISP can change the IP of the
router without any connectivityChange(). This means that if no
connectivityChange() the address in the candidates will be incorrect
if the public ip is changed by the ISP.
The idea here is to get the public IP as soon as the IceOptions are
generated.
This changes the signature of getIceOptions() and removes it from
Account. After all, the account has no need to always manage ICE
the same way (maybe one day we will have accounts without ICE).
GitLab: #534
Change-Id: I56613e9ce48ef21f66dcf188d33334802aae601b
