When a stasis channel is stolen by another app, the control
structure is unreffed but never unlinked from the app_controls
container. This causes the channel reference to leak.
Added OBJ_UNLINK to the callback in channel_stolen_cb.
Also added some additional channel lifecycle debug messages to
channel.c.
ASTERISK-27059 #close
Repoorted-by: George Joseph
Change-Id: Ib820936cd49453f20156971785e7f4f182c56e14
Not easy to reproduce, but we have noticed deadlocks when unloading a module
while dialplan is handling a request.
The deadlock is between :
1) Dialplan execution: pbx_extension_helper() first taking conlock,
then pbx_findapp() [when called] asking for lock on apps list.
2) Application unregistration: ast_unregister_application() first taking lock
on apps list, then unreference_cached_app() [when called] asking for conlock.
As a protection, I suggest to modify ast_unregister_application(), so that it
anticipates the need of conlock, before taking the lock on apps list.
The side effect is a longer unavailability of conlock when unregistering an
application.
ASTERISK-27041
Change-Id: I0db0f1eb320da6a5758cce3a47d765be1face8e2
* changes:
SDP: Set the remote c= line in RTP instance.
SDP: Add t= line in sdp_create_from_state()
stream: Ignore declined streams for some topology calls.
* Pulled finding the rtcp-mux attribute flag out of the ICE candidate for
loop. Also ordered the RTCP ICE candidate skip test to fail earlier.
Change-Id: I8905d9c68563027a46cd3ae14dbcc27e9c814809
* Made ast_format_cap_from_stream_topology() not include any formats from
declined streams.
* Made ast_stream_topology_get_first_stream_by_type() ignore declined
streams to return the first active stream of the type.
* Updated unit tests to check these changes have the expected effect.
Change-Id: Iabbc6a3e8edf263a25fd3056c3c614407c7897df
The ast_channel_suppress function wrongly decremented the
reference count of the underlying structure used to keep
track of what should be suppressed on a channel if the
function was called multiple times on the same channel.
This change cleans up the reference counting a bit so
this no longer occurs.
ASTERISK-27016
Change-Id: I2eed4077cb4916e6626f9f120b63b963acc5c136
This change adds a deferred queue to bridging. If a bridge
technology determines that a frame can not be written and
should be deferred it can indicate back to bridging to do so.
Bridging will then requeue any deferred frames upon a new
channel joining the bridge.
This change has been leveraged for T.38 request negotiate
control frames. Without the deferred queue there is a race
condition between the bridge receiving the T.38 request
negotiate and the second channel joining and being in the
bridge. If the channel is not yet in the bridge then the T.38
negotiation fails.
A unit test has also been added that confirms that a T.38
request negotiate control frame is deferred when no other
channel is in the bridge and that it is requeued when a new
channel joins the bridge.
ASTERISK-26923
Change-Id: Ie05b08523f399eae579130f4a5f562a344d2e415
FreeBSD does not include a crypt.h include file. Definitions for
crypt() and crypt_r() are in unistd.h
ASTERISK-27042 #close
Change-Id: Ib307ee5e384870c6af50efa89fb73722dd0c3a7e
ASTERISK-26419 introduced a bug when calling ast_audiohook_write_list in
ast_write. It would free the frame given to ast_write if the frame returned
by ast_audiohook_write_list was different than the given one. The frame give
to ast_write should never be freed within that function. It is the caller's
resposibility to free the frame after writing (or when it its done with it).
By freeing it within ast_write this of course led to some memory corruption
problems.
This patch makes it so the frame given to ast_write is no longer freed within
the function. The frame returned by ast_audiohook_write_list is now subsequently
used in ast_write and is freed later. It is freed either after translate if the
frame returned by translate is different, or near the end of ast_write prior to
function exit.
ASTERISK-26973 #close
Change-Id: Ic9085ba5f555eeed12f6e565a638c3649695988b
Before this patch, when a user hung up during a Background, we would
stuff 0xff into a char and attempt a dialplan lookup of it. This caused
problems for some realtime engines which interpreted the value as the
beginning of an invalid UTF-8 sequence.
ASTERISK-19291 #close
Reported by: Andrew Nowrot
Change-Id: I8ca6da93252d61c76ebdb46a4aa65e73ca985358
In review 4843 (ASTERISK-24858), we added a hack that forced a smoother
creation when sending signed linear so that the byte order was adjusted
during transmission. This was needed because smoother flags were lost
during the new format work that was done in Asterisk 13.
Rather than rolling that same hack into res_rtp_multicast, re-introduce
smoother flags so that formats can dictate their own options.
Change-Id: I77b835fba0e539c6ce50014a984766f63cab2c16
A previous commit added plumbing to bridge_softmix to allow for an SFU
experience with Asterisk. This commit adds an option to app_confbridge
that allows for a confbridge to actually make use of the SFU video mode.
SFU mode is implemented in a "set it and forget it" kind of way. That
is, when the bridge is created, if SFU mode is enabled, then the video
mode gets set to SFU and cannot be changed. Future improvements may
allow for a hybrid experience (e.g. forward multiple video streams,
specifically those of the most recent talkers), but for this addition,
no such capability is present.
Change-Id: I87bbcb63dec6dbbb42488f894871b86f112b2020
This sets up the "plumbing" in bridge_softmix to
be able to accommodate Asterisk asking as an SFU
(selective forwarding unit) for conferences.
The way this works is that whenever a channel enters or leaves a
conference, all participants in the bridge get sent a stream topology
change request. The topologies consist of the channels' original
topology, along with video destination streams corresponding to each
participants' source video streams. So for instance, if Alice, Bob, and
Carol are in the conference, and each supplies one video stream, then
the topologies for each would look like so:
Alice:
Audio,
Source video(Alice),
Destination Video(Bob),
Destination video (Carol)
Bob:
Audio,
Source video(Bob)
Destination Video(Alice),
Destination video (Carol)
Carol:
Audio,
Source video(Carol)
Destination Video(Alice),
Destination video (Bob)
This way, video that arrives from a source video stream can then be
copied out to the destination video streams on the other participants'
channels.
Once the bridge gets told that a topology on a channel has changed, the
bridge constructs a map in order to get the video frames routed to the
proper destination streams. This is done using the bridge channel's
stream_map.
This change is bare-bones with regards to SFU support. Some key features
are missing at this point:
* Stream limits. This commit makes no effort to limit the number of
streams on a specific channel. This means that if there were 50 video
callers in a conference, bridge_softmix will happily send out topology
change requests to every channel in the bridge, requesting 50+
streams.
* Configuration. The plumbing has been added to bridge_softmix, but
there has been nothing added as of yet to app_confbridge to enable SFU
video mode.
* Testing. Some functions included here have unit tests.
However, the functionality as a whole has only been verified by
hand-tracing the code.
* Selectivenss. For a "selective" forwarding unit, this does not
currently have any means of being selective.
* Features. Presumably, someone might wish to only receive video from
specific sources. There are no external-facing functions at the moment
that allow for users to select who they receive video from.
* Efficiency. The current scheme treats all video streams as being
unidirectional. We could be re-using a source video stream as a
desetnation, too. But to simplify things on this first round, I did it
this way.
Change-Id: I7c44a829cc63acf8b596a337b2dc3c13898a6c4d
During the channel flag audit an incorrect change was
done. The flag should be cleared on the second channel.
ASTERISK-26469
Change-Id: I770c5a389550a2fb5a6ade942fccbb2e1d9199c8
...that can only be run by explicitly calling it with
'test execute category /DO_NOT_RUN/ name RAISE_SEGV'
This allows us to more easily test CI and debugging tools that
should do certain things when asterisk coredumps.
To allow this a new member was added to the ast_test_info
structure named 'explicit_only'. If set by a test, the test
will be skipped during a 'test execute all' or
'test execute category ...'.
Change-Id: Ia3a11856aae4887df9a02b6b081cc777b36eb6ed
Added functions that convert a string to an unsigned integer or unsigned long.
A couple of unit test were also created to test the routines. The reasons for
adding these conversion utilities (and hopefully eventually more) are as
follows:
* Conversion routines are functionally contained with consistent and
better error checking
* The function names offer a better description of what is happening
* It encourages code reuse for easier bug fixing at a single source
* It's simpler to use
* It's unit testable
For instance, currently in a lot of places when converting to an integer or
similar the "sscanf" function is used. When using "sscanf" it may not be
immediately clear what's happening as it lacks semantic naming. Limited error
checking is usually done as well. For example, most of the time a check is done
to make sure the value converted, but does not check for overflows or negative
valued conversions when converting unsigned numbers.
Why use/wrap "strtoul" and not "sscanf" then? Primarily, it lacks some of the
built in error handling that "strtoul" has. For instance "strtoul" contains
overflow checks. Less so, but can still factor as reasons, "sscanf" is slightly
more complex in its use. And maybe a bit controversial, but it may be ("big if")
potentially slower than "strtoul" in some cases.
Change-Id: If7eaca4a48f8c7b89cc8b5a1f4bed2852fca82bb
When manipulating flags on a channel the channel has to be
locked to guarantee that nothing else is also manipulating
the flags. This change introduces locking where necessary to
guarantee this. It also adds helper functions that manipulate
channel flags and lock to reduce repeated code.
ASTERISK-26789
Change-Id: I489280662dba0f4c50981bfc5b5a7073fef2db10
* changes:
SDP: Make process possible multiple fmtp attributes per rtpmap.
SDP: Explicitly stop a RTP instance before destoying it.
SDP: Rework merge_capabilities().
SDP: Update ast_get_topology_from_sdp() to keep RTP map.
The sdp_state.remote_capabilities was only used inside merge_sdps() and
subsequent calls to merge_sdps() by re-INVITE's would leak them.
Change-Id: I0ceb7838ea044cc913e8ad4a255c39c9740ae0ce
When we optionally set the interface_address we are forcing the media to
go out a specific interface address. This allows us to optionally have
the media go out the interface that SIP signalling came in on or if we are
configured to have the media always go out a specific address.
Change-Id: I160d9fac322a075bd2557b430632544178196189
* Made sdp_add_m_from_rtp_stream() and sdp_add_m_from_udptl_stream()
handle generating disabled/declined streams.
* Added /main/sdp/sdp_merge_asymmetric unit test. It currently does not
check the offerer side negotiated SDP because that isn't the purpose of
this patch and there is much to be done to handle declined/dummy streams.
* Added T.38 image streams to the /main/sdp/sdp_merge_symmetric and
/main/sdp/sdp_merge_crisscross unit tests.
Change-Id: Ib4dcb3ca4f9a9133b376f4e3302f9a1f963f2b31
* Tried to give better variable names.
* Made our SDP answer use the offer's RTP payload types as the SDP RFC
says we SHOULD.
* Updating the local topology now takes the stream format caps. We are
likely preparing to send an offer.
Change-Id: I34d3be8e3036402a8575ffcae3eebc5ce348d7c0
This change uses the functions provided by OpenSSL to query
and better construct error messages for situations where
the connection encounters a problem.
ASTERISK-26606
Change-Id: I7ae40ce88c0dc4e185c4df1ceb3a6ccc198f075b
It is possible to initialize a valid config without a capath
or cafile definition. This will cause a crash on a reload.
This fix ensures capath is always allocated.
ASTERISK-26983 #close
Change-Id: I63ff715d9d9023427543a5b8a4ba7b0d82533c12
All log messages go to a queue serviced by a single thread
which does all the IO. This setting controls how big that
queue can get (and therefore how much memory is allocated)
before new messages are discarded. The default is 1000.
Should something go bezerk and log tons of messages in a tight
loop, this will prevent memory escalation.
When the limit is reached, a WARNING is logged to that effect
and messages are discarded until the queue is empty again. At
that time another WARNING will be logged with the count of
discarded messages. There's no "low water mark" for this queue
because the logger thread empties the entire queue and processes it
in 1 batch before going back and waiting on the queue again.
Implementing a low water mark would mean additional locking as
the thread processes each message and it's not worth it.
A "test" was added to test_logger.c but since the outcome is
non-deterministic, it's really just a cli command, not a unit
test.
Change-Id: Ib4520c95e1ca5325dbf584c7989ce391649836d1
Joshua Colp
George Joseph
Frederic LE FOLL
Jenkins2
Richard Mudgett
Guido Falsi
Kevin Harwell
Sean Bright
Mark Michelson
Joshua Elson