This is required to look up the correct interface during Redis restore.
Change-Id: I0ea67576deba95b4201c6384fdcf8051b84f879e
(cherry picked from commit 531e720fd4)
If we're updating the handlers for one particular source -> sink flow,
only stop/reset the handlers matching this flow.
Change-Id: I1d046f47f8d26cac47c5d0f4318498eacb6c5677
(cherry picked from commit e24bacaa4c)
Use `->subscribers.head` instead of `->subscriptions.head`
for the second logging.
Change-Id: Iaaff61aebbe8bcd421a0159f5490903c0ea9c4ea
(cherry picked from commit d9f12ce27b)
g_string_free(..., FALSE) is declared as warn_unused_result
closes#1690
Change-Id: Ib0a7fb4eab4359226fba519cfd485fb3228a0bc7
(cherry picked from commit 37d7762fec)
Creating the codec handler can possibly fail. Catch that case.
Closes#1693
Change-Id: Iebd8d1c6aa3542cd9e1351756148c48ebada38ec
(cherry picked from commit 94ba3e0fa8)
Avoid trying to acquire a recursive lock by making sure the response is
always generated in a different thread.
Fixes#1656
Change-Id: I6c4c5bb52cb95a204823848bb427ab24f42dcccd
(cherry picked from commit 04ce204ef6)
We're supposed to use the remote password for sending STUN error
responses (same as for sending STUN success responses), not the local
one.
Fixes a bug from 2015.
Closes#1626
Change-Id: I975178405dcd41661bdc5e0c1208295f9db70006
(cherry picked from commit 394ed2fc62)
While LWS explicitly allows usage of lws_callback_on_writable() from
other threads, for some reason there is no internal locking in place,
and so a concurrently running lws_service() can interfere with internal
structures, in particular if lws_service() is closing connections at the
same time as lws_callback_on_writable() is invoked.
The suggested approach of using lws_cancel_service() in combination with
the LWS_CALLBACK_EVENT_WAIT_CANCELLED callback and a user-kept queue is
not feasible, as we need to support LWS 2.x, which doesn't have
LWS_CALLBACK_EVENT_WAIT_CANCELLED.
Closes#1624
Change-Id: Ia3ddeda66fd553c87f99404e0816d97ecbd4cdfe
(cherry picked from commit 1457b34f65)
These functions now cannot fail and so returning a value is pointless.
Change-Id: I062449f30f05fb3efa4ba520004a13de3a0abd5a
(cherry picked from commit 26cc168f83)
Avoid calling lws_write() from threads other than the service thread, as
this might not be thread-safe. Instead store the values used for the
HTTP response headers in the websocket_output, then trigger a "writable"
callback, and finally do all the lws_write() calls from the service
thread.
Reported in #1624
Change-Id: Ifcb050193044e5543f750a12fb44f5e16d4c0a08
(cherry picked from commit b207d0c586)
... instead of explicit lock/unlock pairs to save some code lines.
Change-Id: Iece32fb201cd3b662038e91d98443e1dcfd04a63
(cherry picked from commit f293ca9a18)
Removes one level of indentation for prettier code. Functional no-op.
Change-Id: I5f5528944f144499540f34bc1f322d00c9454fa6
(cherry picked from commit cb9ec2abf9)
Don't change to a new port for sendonly streams as this causes problems
with NAT. A device receiving a sendonly SDP with a new port won't send
any RTP to the new port, leading to a closed (non existent) NAT mapping.
Change-Id: I2ea2163eb9f1203226bd781b53f421c790a86f0a
(cherry picked from commit 6d7603e0640407bb7a9231353671aa5bfbb666fe)
The old port latching logic was simply to use the last (newest)
allocated endpoint_map. This turned out to be wrong, because the last
used socket on the monologue could have been one that was allocated
earlier (and older endpoint_map), as it can happen during repeated
re-invites. Add a new function to actually look for the correct
endpoint_map, matching the currently used socket, to make sure the port
doesn't change.
Change-Id: Iae768fe48539264575aed67cbbb6b08ac745130f
(cherry picked from commit 3778d0f3594c501f2406d9be069fa3d1f23afebd)
The SRTP decryption context is associated with the local socket. Use the
socket that a packet was actually received on for the decryption context
instead of using the one that it was expected to be received on.
Change-Id: Iddf400a440fc51b4afb370ec827f75e9626b2cfd
When a receiving socket doesn't match the socket we were expecting, make
sure that the receiving socket is actually one of the sockets we want to
use at this point before blindly switching the socket.
This fixes a race condition after a re-invite: A new set of sockets has
been opened, but an old/delayed RTP packet still arrives on one of the
old ports. In this case we don't want to switch the local socket.
Change-Id: I4e2b87ad608b1a9c6a0bb2eae5c305fd79be70d5
As Redis updates must be triggered with the call unlocked, use a
convenience wrapper function to unlock, update, unref.
fixes#1602
Change-Id: I67095f31fb605b6977c88d9e9b3db581dd71a0d9
The data in Redis must be updated after a successful publish/subscribe.
closes#1602
Change-Id: If39cbf04cf1c20e04b390b0b865c473a9acdb2ab
(cherry picked from commit cf6aa99dae)
Many of the SIP stacks use 32-bit integers internally and the Asterisk chan_sip SDP decoder will cap version to 9223372036854775807.
(cherry picked from commit 2351d7f6ac)
1) Read dtxb->start while the lock is held (not strictly necessary as
the read should be atomic anyway)
2) Expect that dtxb->start can be larger than rtpe_now.tv
The latter can happen as `rtpe_now` in a timer thread is faked to be
exactly the time when the timer was supposed to run, and not the actual
current time, which means that a newly added packet can have a later
time stamp than the "now" the timer thread is using.
Change-Id: I48fd7f78af97c6d5b802e5151d69855a90f4032d
Usually supplemental RTP types (DTMF) are listed after the primary audio
codecs. In the case of the order being reversed, fix `single-codec` so
that it doesn't strip the actual audio codec that is listed after the
DTMF type.
Change-Id: I1b03b89e31bebf4de303b643dcf08d2ffb90ebaf
In some cases it's possible that some packets still arrive in userspace
immediately after a stream has been pushed to the kernel, for example if
some packets are already in the queue or if there is some processing
delay (e.g. writing to Redis). Allow for a short delay before counting a
stream as userspace if it has been pushed to the kernel.
Change-Id: I55a6e255868c8c2a9e93355a4aa2287f07b3748d
(cherry picked from commit 8a99171200)
(cherry picked from commit 0cbf96b187)
On bookworm and later, libasan reports a false positive in combination
with pthread_cleanup_push() (see [1]). Work around this by not using the
thread cleanup handler when running the asan build, and instead use a
shorter thread sleep time.
[1] https://gcc.gnu.org/bugzilla//show_bug.cgi?id=82109
Change-Id: Ieffdc0b13f470445f1f8e1d2448c6af6d8dd68e0
(cherry picked from commit c9a5714df7)
Keep the maximum time for a thread to sleep in a central place
Change-Id: Id4445f40d34648a2efbcbf17d67f2921c7dedf46
(cherry picked from commit 0c4fc1c31d)
Convenience macros to enable and disable thread cancellation
Change-Id: I1c588af83a4c6a45c60b60d941aa446b07e72978
(cherry picked from commit 08a05e76ec)
Legacy UDP/TCP control protocols don't provide information about RTP
payload types, therefore don't pretend that we know that this is RTP.
Setting the RTP flag without knowing the payload types has the undesired
side effect that unknown payload types (all of them) would not be
handled by the kernel module.
Change-Id: I5882f777a5912b912ec7c870f21c77aac8127600
(cherry picked from commit e811cd474d)
Instead of just leaving the transport protocol unset when we know we're
not supposed to be aware of the protocol, add a special entry to
suppress the pointless warning message.
Change-Id: I228c2f1652320627f974d9d7bcb0b1345adce2be
(cherry picked from commit 7ed04c3949)
Legacy protocols don't set sp->num_ports. Use a sensible default for
this case.
Probably a regression from 2d2d7665b
Change-Id: Idcbc477a68b6db70a91a5d082736ac642c50ab15
(cherry picked from commit 302f7d6457)
Move some code around to eliminate some redundant code paths.
Change-Id: I419728376aafe2561b5a2224b2f635d505936ee3
(cherry picked from commit 7a5069b194)
This is a regression from the overhaul of the stats bookkeeping code.
Change-Id: I9b7c2084fb20407e5a2a24fdf802b8fd6831dc75
(cherry picked from commit 9a3ced05ff)
The packet must be decrypted first before RTP padding can be considered,
as the padding count is part of the encrypted payload as well.
Change-Id: I6aecff636efd420401856bb8110b3d784f989179
(cherry picked from commit 9e09cf3c40)
If an offer is going to a side that is already known to support
rtcp-mux, don't try to offer a fallback RTCP port. Do this by pretending
that rtcp-mux=require is set, which leads to the correct behaviour. This
is needed because the RTCP fallback port might already be closed, so
trying to include it in the offer would require opening a new set of
ports, which is undesirable.
closes#1494
Change-Id: I550bec08379c799cb7dd090a70d090ae47462467
(cherry picked from commit 3ac4863a94)
Newer libwebsockets versions seem to use a longer internal timeout, so
an explicit "interrupt" is needed during shutdown to prevent a long wait
time.
Change-Id: I8f28ef658169178e35b40dd44520fbd7c812b590
(cherry picked from commit 9eb7b640c2)
Zero SSRC are technically invalid, but the code accepts them as valid
and therefore sets up things like crypto contexts for zero SSRCs.
Consequently it's possible to have a zero SSRC first in the list of
SSRCs and other valid SSRCs later in the list, which means we can't use
the presence of a non-zero SSRC first in the list as a flag to determine
whether SSRC tracking is in use or not. Use an explicit flag instead.
Change-Id: I88736e5d6b0f66c58f8d675137231760951e7610
(cherry picked from commit 85ec6e2870)
Don't increase the index pointer before using it. This fixes slots 1 and
2 being filled before slot 0, which ends up filling slots 0 and 2 first
(due to swapping with slot 0), leaving slot 1 empty.
Change-Id: If34cf561fcb153edde6408252c3286c8c80991bc
(cherry picked from commit 6d26df0580)
Starting with release 5.1, ffmpeg obsoletes the `channels` and
`channel_layout` fields, replacing them with a unified `ch_layout`
struct of type AVChannelLayout. Add wrapper defines into the
compile-time build-test headers fix_frame_channel_layout*.h to
accommodate both new and old versions.
Change-Id: I3d43b85dc3140155a61b1cf2269cda166ad88e9a
(cherry picked from commit 206ea9efd5)
Keyspace notifications are set up before existing calls are restored
(restore_thread). Therefore the following scenario is possible:
NOTIF THREAD: receives SET, creates call
RESTORE THREAD: executes KEYS *
NOTIF THREAD: receives another SET:
NOTIF THREAD: does call_destroy(), which:
adds ports to late-release list
RESTORE THREAD: comes across call ID, does GET
RESTORE THREAD: creates new call
RESTORE THREAD: wants to allocate ports, but they're still in use
NOTIF THREAD: now does release_closed_sockets()
Use a multi-A multi-B lock to protect the two code sections from each
other and make sure that notification threads have always released all
ports before a restore thread attempts to allocate any.
Reported in #1503
Change-Id: I322062488e2ce3515c5a3e6609a5700830ac1fd4
To prevent a race condition that might miss updates about call info, set
up the Redis keyspace notifications first and then run loop to restore
calls from the existing data.
closes#1503
Change-Id: I6afa4c50fe0a34c602063fc2f45b2ee38133cf1e
Richard Fuchs
Donat Zenichev
Dennis Yurasov
Lasse Bang Mikkelsen