* Use ast_cli_completion_add() to improve performance when large number of
cached items are present.
* Only complete one URI for commands that only accept a single URI.
* Change command documentation to wrap at 80 characters to improve
readability.
Change-Id: Iedb0a2c3541e49561bc231dca2dcc0ebd8612902
If an AMI user without the "system" authorization calls the
Originate AMI command with the Originate application,
the second Originate could run the "System" command.
Action: Originate
Channel: Local/1111
Application: Originate
Data: Local/2222,app,System,touch /tmp/owned
If the "system" authorization isn't set, we now block the
Originate app as well as the System, Exec, etc. apps.
ASTERISK-28580
Reported by: Eliel Sardañons
Change-Id: Ic4c9dedc34c426f03c8c14fce334a71386d8a5fa
The current code sets alert levels starting from index 1.
Need to set on whole pool starting from index 0.
Change-Id: I5decbb43160954fb9a512f04302637fc666b6f5d
This patch fixes several issues reported by the lgtm code analysis tool:
https://lgtm.com/projects/g/asterisk/asterisk
Not all reported issues were addressed in this patch. This patch mostly fixes
confirmed reported errors, potential problematic code points, and a few other
"low hanging" warnings or recommendations found in core supported modules.
These include, but are not limited to the following:
* innapropriate stack allocation in loops
* buffer overflows
* variable declaration "hiding" another variable declaration
* comparisons results that are always the same
* ambiguously signed bit-field members
* missing header guards
Change-Id: Id4a881686605d26c94ab5409bc70fcc21efacc25
* Pass caller information to frame allocation functions.
* Disable caching as it interfers with MALLOC_DEBUG reporting.
* Stop using ast_calloc_cache.
Change-Id: Id343cd80a3db941d2daefde2a060750fea8cd260
Here's the basic scenario that occurred when executing an AMI fast originate
while at the same time something else locks the channels container, and also
wants a lock on the dialed channel:
1. pbx_outgoing_attempt obtains a lock on a dialed channel
2. concurrently another thread obtains a lock on the channels container, and
subsequently requests a lock on the dialed channel. It waits on #1. For
instance, "core show channel <dialed channel"
3. the outgoing call does not fail, but ends before the pbx_outgoing_attempt
function exits
4. pbx_outgoing_attempt function exits, the outgoing structure destructs, and
attempts to hang up the dialed channel
5. hang up tries to obtain the channels container lock, but can't due to #2.
6. Asterisk is deadlocked.
The solution was to allow the pbx_outgoing_exec function to "steal" ownership
of the dialed channel, and handle hanging it up. The channel now is either hung
up prior to it being potentially locked by the initiating thread, or if locked
the hang up takes place in a different thread, thus alleviating the deadlock.
ASTERISK-28561
patches:
iliketrains.diff submitted by Joshua Colp (license 5000)
Change-Id: I51b42b92dde8f2215b69bb509e28667ee3a3853a
Serializer pools have previously existed in Asterisk. However, for the most
part the code has been duplicated across modules. This patch abstracts the
code into an 'ast_serializer_pool' object. As well the code is now centralized
in serializer.c/h.
In addition serializer pools can now optionally be monitored by a shutdown
group. This will prevent the pool from being destroyed until all serializers
have completed.
Change-Id: Ib1e906144b90ffd4d5ed9826f0b719ca9c6d2971
This avoids use of the global variable and ensures topic_all remains
active until all topics are freed.
ASTERISK-28553
patches:
ASTERISK-28553.patch by coreyfarrell (license 5909)
Change-Id: I9a8cd8977f3c3a6aa00783f8336d2cfb9c2820f1
pbx_extension_helper takes two 'context' arguments. One (con) is a
pointer directly to a 'struct ast_context' and the other (context) is
the name of the context. In all cases, one of these arguments is NULL
and the other is non-NULL.
Functions that are ultimately called by pbx_extension_helper expect that
'context' will be non-NULL, so we set it unconditionally on entry into
this function.
ASTERISK-28534 #close
Change-Id: Ifbbc5e71440afd80efd441f7a9d72e8b10b6f47d
Added "like" support for 'core show taskprocessors'. Now you
can specify a specific set of taskprocessors (or just one) by
adding the keyword "like" to the above command, followed by
your search criteria.
Change-Id: I021e740201e9ba487204b5451e46feb0e3222464
This improves the way which stasis_state reference counting works.
Since manager->states holds onto the proxy object instead of the real
object this allows stasis_state objects to be freed when appropriate
without use of a special state_remove function. Additionally each
distinct eid associated with the state holds a reference to the state to
prevent early release and potentially allow easier debug of leaks.
Change-Id: I400e0db4b9afa3d5cb4ac7dad60907897e73f9a9
Added two new CLI commands to reset stats for taskprocessors. You can
reset stats for a single, specific taskprocessor ('core reset
taskprocessor <taskprocessor>'), or you can reset all taskprocessors
('core reset taskprocessors'). These commands will reset the counter for
the number of tasks processed as well as the max queue size.
Change-Id: Iaf17fc4ae29396ab0c6ac92408fc7bdc2f12362d
Previous to this patch passing a NULL tag to ao2_alloc or ao2_ref based
functions would result in the reference not being logged under
REF_DEBUG. This could sometimes cause inaccurate logging if NULL was
accidentally passed to a reference action. Now reference logging is
only disabled by option passed to the allocation method.
Change-Id: I3c17d867d901d53f9fcd512bef4d52e342637b54
You can currently capture backtraces of memory allocations but they
only get displayed when you stop asterisk and the atexit hooks
are enabled. Now, if memory backtrace is on and you issue a
"memory show allocations" CLI command for a specific file, then
a backtrace will show for each allocation that occurred after
you turned "memory backtrace on". The backtrace display is shown
only when a specific file's allocations are displayed to prevent
a massive CLI dump of every file's allocations.
Change-Id: Ic657afc1fc6ec7205e16eb36a97a611d235a2b4f
astobj2.c declares DEBUG_THREADS_LOOSE_ABI to avoid overhead of debug
threads tracking information in the internal structures of astobj2.
Unfortunately this means that ao2_global_obj contains the statically
allocated debug threads tracking fields which are used by initialization
and cleanup but main/astobj2.c believed those fields and associated
space did not exist.
Change-Id: Icef41ad97d88a8c1d1515e034ec8133cab3b1527
It is possible for topic->name to be NULL, this causes the allocation
reference to not be logged. Use the name variable instead which has
been verified to be a non-empty.
Change-Id: I3d0031d03c8356e4808f00cdf2d5428712575883
* Release reference returned by cache_remove
* state_alloc unconditionally bumped state_topic even when it was
locally allocated.
Change-Id: I51101bf7d07b8dc8ce8fc46b6cb31fbbd213fbc7
This change adds support to the JITTERBUFFER dialplan function
for audio and video synchronization. When enabled the RTCP SR
report is used to produce an NTP timestamp for both the audio and
video streams. Using this information the video frames are queued
until their NTP timestamp is equal to or behind the NTP timestamp
of the audio. The audio jitterbuffer acts as the leader deciding
when to shrink/grow the jitterbuffer when adaptive is in use. For
both adaptive and fixed the video buffer follows the size of the
audio jitterbuffer.
ASTERISK-28533
Change-Id: I3fd75160426465e6d46bb2e198c07b9d314a4492
This change adds H.265/HEVC as a known codec and creates a cached
"h265" media format for use.
Note that RFC 7798 section 7.2 also describes additional SDP
parameters. Handling of these is not yet supported.
ASTERISK-28512
Change-Id: I26d262cc4110b4f7e99348a3ddc53bad0d2cd1f2
When modifying an already defined variable in some channel drivers they
add a new variable with the same name to the list, but that value is
never used, only the first one found.
Introduce ast_variable_list_replace() and use it where appropriate.
ASTERISK-23756 #close
Patches:
setvar-multiplie.patch submitted by Michael Goryainov
Change-Id: Ie1897a96c82b8945e752733612ee963686f32839
Added unit tests for RTCP video stats. These tests include NACK, REMB,
FIR/FUR/PLI, SR/RR/SDES, and packet loss statistics. The REMB and FIR
tests are currently disabled due to a bug. We expect to receive a
compound packet, but the code sends this out as a single packet, which
the browser accepts, but makes Asterisk upset.
While writing these tests, I noticed an issue with NACK as well. Where
it is handling a received NACK request, it was reading in only the first
8 bits of following packets that were also lost. This has been changed
to the correct value of 16 bits.
Also made a minor fix to the data buffer unit test.
Change-Id: I56107c7411003a247589bbb6086d25c54719901b
This change removes the assumption that a frame will always have
a src set on it. This assumption is incorrect.
Given a scenario where an RTP packet is received with no payload
the resulting audio frame will have no samples. If this frame goes
through a signed linear translation path an interpolated frame can
be created (if generic packet loss concealment is enabled) that has
minimal data on it, including no src. If this frame is given to a
translation path a crash will occur due to the lack of src.
ASTERISK-28499
Change-Id: I024d10dd98207eb8a6b35b59880bcdf1090538f8
The new function takes in a pointer to an ast_sockaddr structure,
a hostname and an optional port and then dispatches parallel
"AAAA" and "A" record queries. If an "AAAA" record is returned,
it's parsed into the ast_sockaddr structure along with the port
if it was supplied. If no "AAAA" record was returned, the
first "A" record returned (if any) is parsed instead.
This is a synchronous call. If you need asynchronous lookups,
use ast_dns_query_set_resolve_async and roll your own.
Change-Id: I194b0b0e73da94b35cc35263a868ffac3a8d0a95
There are 4 scenarios to consider when capturing audio from a channel
with an audiohook:
1. There is no rx and no tx audio, so return nothing.
2. There is rx but no tx audio, so return rx.
3. There is tx but no rx audio, so return tx.
4. There is rx and tx audio, so mix them and return.
The file passed as the primary argument to MixMonitor will be written to
in scenarios 2, 3, and 4. However, if you pass the r() and t() options
to MixMonitor, a frame will only be written to the r() file if there was
rx audio and a frame will only be written to the t() file if there was
tx audio.
If you subsequently take the r() and t() files and try to mix them, the
sides of the conversation will 'drift' and be non-representative of the
user experience.
This patch adds a new 'S' option to MixMonitor that injects a frame of
silence on either the r() side or the t() side of the channel so that
when later mixed, there is no such drift.
Change-Id: Ibf5ed73a811087727bd561a89a59f4447b4ee20e
Somehow it's possible for the srtp session object to be NULL even though the
Asterisk srtp object itself is valid. When this happened it would cause a
crash down in the srtp code when attempting to protect or unprotect data.
After looking at the code there is at least one spot that makes this situation
possible. If Asterisk fails to unprotect the data, and after several retries
it still can't then the srtp->session gets freed, and set to NULL while still
leaving the Asterisk srtp object around. However, according to the original
issue reporter this does not appear to be their situation since they found
no errors logged stating the above happened (which Asterisk does for that
situation).
An issue was found however, where a possible race condition could occur between
the pjsip incoming negotiation, and the receiving of RTP packets. Both places
could attempt to create/setup srtp for the same rtp instance at the same time.
This potentially could be the cause of the problem as well.
Given the above this patch adds locking around srtp setup for a given rtp, or
rtcp instance. NULL checks for the session have also been added within the
protect and unprotect functions as a precaution. These checks should at least
stop Asterisk from crashing if it gets in this situation again.
This patch also fixes one other issue noticed during investigation. When doing
a replace the old object was freed before creating the replacement. If the new
replacement object failed to create then the rtp/rtcp instance would now point
to freed srtp data which could potentially cause a crash as well when the next
attempt to reference it was made. This is now fixed so the old srtp object is
kept upon replacement failure.
Lastly, more logging has been added to help diagnose future issues.
ASTERISK-28472
Change-Id: I240e11cbb1e9ea8083d59d50db069891228fe5cc
When updating times on CDR or CEL records using the time at which
it is done can result in times being incorrect if the system is
heavily loaded and stasis message processing is delayed.
This change instead makes it so CDR and CEL use the time at which
the stasis messages that drive the systems are created. This allows
them to be backed up while still producing correct records.
ASTERISK-28498
Change-Id: I6829227e67aefa318efe5e183a94d4a1b4e8500a
There were still a few places in the code that could overflow when "packing"
a json object with a value outside the base type integer's range. For instance:
unsigned int value = INT_MAX + 1
ast_json_pack("{s: i}", value);
would result in a negative number being "packed". In those situations this patch
alters those values to a ast_json_int_t, which widens the value up to a long or
long long.
ASTERISK-28480
Change-Id: Ied530780d83e6f1772adba0e28d8938ef30c49a1
incorrect handling of UDPTL squence number wrap arounds causes
loss of packets every time the wrap around occurs
ASTERISK-28483 #close
Change-Id: I33caeb2bf13c574a1ebb81714b58907091d64234
The functions that build manager message headers do so in a way that
results in a single messages being split across multiple packets. While
this doesn't matter to the remote end, it makes network captures noisier
and harder to follow, and also means additional system calls.
With this patch, we build up more of the message content into the TLS
buffer before flushing to the network. This change is completely
internal to the manager code and does not affect any of the existing
API's consumers.
Change-Id: I50128b0769060ca5272dbbb5e60242d131eaddf9
When a module fails to register itself (usually a coding error
in the module), dlerror() can return NULL. We weren't checking
for that in load_dlopen() before trying to strdup the error message
so a SEGV was thrown. dlerror() is now surrounded with an S_OR
so we don't SEGV.
Change-Id: Ie0fb9316f08a321434f3f85aecf3c7d2ede8b956
When fixing ASTERISK~24212, a change was done so a scheduled callback could not
be removed while it was running. The caller of ast_sched_del would have to wait.
However, when the caller of ast_sched_del is the callback itself (however wrong
this might be), this new check would cause a deadlock: it would wait forever
for itself.
This changeset introduces an additional check: if ast_sched_del is called
by the callback itself, it is immediately rejected (along with an ERROR log and
a backtrace). Additionally, the AST_SCHED_DEL_UNREF macro is adjusted so the
after-ast_sched_del-refcall function is only run if ast_sched_del returned
success.
This should fix the following spurious race condition found in chan_sip:
- thread 1: schedule sip_poke_peer_now (using AST_SCHED_REPLACE)
- thread 2: run sip_poke_peer_now
- thread 2: blank out sched-ID (too soon!)
- thread 1: set sched-ID (too late!)
- thread 2: try to delete the currently running sched-ID
After this fix, an ERROR would be logged, but no deadlocks (in do_monitor) nor
excess calls to sip_unref_peer(peer) (causing double frees of rtp_instances and
other madness) should occur.
(Thanks Richard Mudgett for reviewing/improving this "scary" change.)
Note that this change does not fix the observed race condition: unlocked
access to peer->pokeexpire (and potentially other scheduled items in chan_sip),
causing AST_SCHED_DEL_UNREF to look at a changing id. But it will make the
deadlock go away. And in the observed case, it will not have adverse affects
(like memory leaks) because the scheduled item is removed through a different
path.
ASTERISK-28282
Change-Id: Ic26777fa0732725e6ca7010df17af77a012aa856
When manager debugging is turned on, this patch makes it so incoming AMI actions
are now also logged.
Change-Id: I8047524510e7ac97d99482b2448f8e368f29cd47
