So this issue is a bit complicated. Since it is possible to pass values to AMI
that contain a '\r\n' (or other similar sequences) these values need to be
escaped. One way to solve this is to escape the values and then pass the escaped
values to the AMI variable parameter string building function. However, this
puts the onus on the pre-build function to escape all string values. This
potentially requires a fair amount of changes along with a lot of string
allocations/freeing for all values.
Surely there is a way to push this complexity down a level into the string
building function itself? This of course is possible, but ends up requiring a
way to distinguish between strings that need to be escaped and those that don't.
The best way to handle this is by introducing a new format specifier in the
format string. For instance a %s (no escape) and %S (escape). However, that is
a bit weird and unexpected.
So faced with those possibilities this patch implements a limited version of the
first option. Instead of attempting to escape all string values this patch only
escapes those values that make sense. This approach limits the number of changes
and doesn't suffer from the odd format specifier problem.
ASTERISK-24934 #close
Reported by: warren smith
Change-Id: Ib55a5b84fe0481b0f2caaaab68c566f392c0aac0
* Add some type casting so tv_usec can really be a long, instead of
some strange platform specific type.
* Add some .dylib style files to .gitignore.
* Switch from using -Xlinker to -Wl,. For [reasons unknown][], newer
versions of GCC, when compiling the Homebrew formula for Asterisk,
are not properly passing the -Xlinker options to the linker. Given
that -Wl, does exactly the [same thing][], and does it properly, this
patch changes the -Xlinker options to use -Wl, instead.
[reasons unknown]: http://bit.ly/1SUbEYx
[same thing]: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
Change-Id: Id5e6b3c6cc86282ea5fca630dc3991137c5bf4dd
When an endpoint was created, it's messages were being forwarded to
both the tech endpoint topic and the all endpoints topic. Since
the tech topic was also forwarded to all, this was resulting in
duplicate messages whenever an endpoint published. This patch
causes the endpoint to only forward to the tech topic and lets
the tech topic forward to all.
To accomplish this, the existing stasis_cp_single_create function
(which both creates and forwards) was cloned and split into 2
functions, one that creates the topic and one that sets up the
forwarding. This allows endpoint_internal_create to create
the topic from the endpoint_all cache without forwarding it there,
then allows it to do the forward to the tech's topic.
ASTERISK-25137 #close
Reported-by: Vitezslav Novy
ASTERISK-25116 #close
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
Change-Id: I26d7d4926a0861748fd3bdffe316b75b549a801c
Add a new ContactStatus AMI event.
Publish the following status/state changes:
Created
Removed
Reachable
Unreachable
Unknown
Contact URI, new status/state, aor and endpoint names, and the
last qualify rtt result are included in the event.
ASTERISK-25114 #close
Change-Id: Id25aae5f7122facba183273efb3e8f36c20fb61e
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
The cache creation callback function expects to receive a sorcery_details
structure and not just a standalone object.
Change-Id: I3e4a5a137cb25292eb52d7a14cbb6daa09213450
The code in astobj2_hash.c wrongly assumed that abs(int) is always > 0.
However, abs(INT_MIN) = INT_MIN and is still negative, as well as
abs(INT_MIN) % num_buckets, and as a result this led to a crash.
One way to trigger the bug is using host=::80 or 0.0.0.128 in peer
configuration section in chan_sip or chan_iax.
This patch takes the remainder before applying abs, so that bucket
number is always in range.
ASTERISK-25100 #close
Reported by: Mark Petersen
Change-Id: Id6981400ad526f47e10bcf7b847b62bd2785e899
Many uses of stasis_unsubscribe in modules can be reached through unload.
These have been switched to stasis_unsubscribe_and_join.
Some subscription callbacks do nothing, for these I've created a noop
callback function in stasis.c. This is used by some modules that monitor
MWI topics in order to enable cache, since the callback does not become
invalid after dlclose it is safe to use stasis_unsubscribe on these, even
during module unload.
ASTERISK-25121 #close
Change-Id: Ifc2549fbd8eef7d703c222978e8f452e2972189c
Reset options to default values before reloading config. This ensures
that if a setting is removed or commented out of the configuration file
it is unset on reload.
ASTERISK-25112 #close
Reported by: Corey Farrell
Change-Id: Id24bb1fb0885c2c14cf8bd6f69a0c2ee7cd6c5bd
If a channel hangs up while an audio file is playing, there's
no need to clutter up the logs with a warning so suppress it
if ast_check_hangup returns true.
Also, change warning to debug/2 in file.c if writing a frame
fails. Same reasoning.
Change-Id: I2e66191af3c5b6e951c98e8f1c3fe3cf2cf7ed89
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
Currently, everytime a sample rate change occurs (on read or write) the
associated factory buffers are reset. If the requested sample rate on a
read differed from that of a write then the buffers are continually reset
on every read and write. This has the side effect of emptying the buffer,
thus there being no data to read and then write to a file in the case of
call recording.
This patch fixes it so that an audiohook_list's rate always maintains the
maximum sample rate among hooks and formats. Audiohook sample rates are
only overwritten by this value when slin native compatibility is turned on.
Also, the audiohook sample rate can only overwrite the list's sample rate
when its rate is greater than that of the list or if compatibility is
turned off. This keeps the rate from constantly switching/resetting.
ASTERISK-24944 #close
Reported by: Ronald Raikes
Change-Id: Idab4dfef068a7922c09cc631dda27bc920a6c76f
The config wizard was always pulling the first occurrence of
a variable from an ast_variable list but this gets the template
value from the list instead of any overridden value. This patch
creates ast_variable_find_last_in_list() in config.c and updates
res_pjsip_config_wizard to use it instead of
ast_variable_find_in_list. Now the overridden values, where they
exist, are used instead of template variables.
Updated test_config to test the new API.
ASTERISK-25089 #close
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
Change-Id: Ifa7ddefc956a463923ee6839dd1ebe021c299de4
When the new Bridging API was implemented, the workspace variable
changed to a malloc'd string, causing sizeof() to always be 8 (char).
Revert back to stored on stack string for workspace.
ASTERISK-25090 #close
Change-Id: I51e610ae87371df771ce7693a955510efb90f8f7
The message channel is a special channel that doesn't actually process frames.
However, certain actions can cause frames to be placed in the channel's read
queue including the Hangup application which is called on the channel after
each message is processed. Since the channel will continually be reused for
many messages, it's necessary to flush these frames at some point.
ASTERISK-25083 #close
Reported by: Jonathan Rose
Change-Id: Idf18df73ccd8c220be38743335b5c79c2a4c0d0f
Fix the alphabetic order added on ast_manager_register_struct. The order
for struct manager_action added is not working, this change fixes the
problem.
Change-Id: I149da0cd06c3c4445d7516cc303358e9f26f8b4b
Currently you can 'apply' a wizard to an object type but the wizard
always goes at the end of the object type's wizard list. This patch
adds a new ast_sorcery_insert_wizard_mapping function that allows
you to insert a wizard anyplace in the list. I.E. You could
add a caching wizard to an object type and place it before all
wizards.
ast_sorcery_get_wizard_mapping_count and
ast_sorcery_get_wizard_mapping were added to allow examination
of the mapping list.
ast_sorcery_remove_mapping was added to remove a mapping by name.
As part of this patch, the object type's wizard list was converted
from an ao2_container to an AST_VECTOR_RW.
A new test was added to test_sorcery for this capability.
ASTERISK-25044 #close
Change-Id: I9d2469a9296b2698082c0989e25e6848dc403b57
The code which reads asterisk.conf supports processing the debug
option with ast_true, but ast_true returns -1. This causes debug
to still be off, convert to 1 so debug will be on as requested.
ASTERISK-25042
Reported by: Corey Farrell
Change-Id: I3c898b7d082d914b057e111b9357fde46bad9ed6
ERR_remove_state was deprecated with OpenSSL 1.0.0 and was replaced by
ERR_remove_thread_state. ERR_load_SSL_strings and ERR_load_BIO_strings were
called by SSL_load_error_strings already and got removed. These changes allow
OpenSSL forks like BoringSSL to be used with Asterisk.
ASTERISK-25043 #close
Reported by: Alexander Traud
patches:
asterisk_with_BoringSSL.patch uploaded by Alexander Traud (License 6520)
Change-Id: If1c0871ece21a7e0763fafbd2fa023ae49d4d629
(cherry picked from commit 247fef6653)
A crash happens with this sequence of steps:
1) Party A is connected to party B.
2) Party B starts a DTMF attended transfer.
3) Party A hangs up while party B is dialing party C.
When party A hangs up the bridge that party A and party B are in is
dissolved and party B is kicked out of the bridge. When party B finishes
dialing party C he attempts to move to the new bridge with party C. Since
party B is no longer in a bridge the attempted move dereferences a NULL
bridge_channel pointer and crashes.
* Made the hold(), unhold(), ringing(), and the bridge_move() functions
tolerant of the channel not being in a bridge. The assertion that party B
is always in a bridge is not true if the bridged peer of party B hangs up
and dissolves the bridge. Being tolerant of not being in a bridge allows
the peer hangup stimulus to be processed by the FSM.
* Made the bridge_move() function return void since where the return value
for a failed move was checked generated a FSM coding ERROR message for a
normal off-nominal condition.
* Eliminated most uses of RAII_VAR in bridge_basic.c.
ASTERISK-25003 #close
Reported by: Artem Volodin
Change-Id: Ie2c1b14e5e647d4ea6de300bf56d69805d7bcada
A recent change went into Asterisk which added reference counts to the
channels stored in a dial masquerade datastore. Unfortunately this
included a reference to the caller in a dialing operation. While all
of the dialed targets have the datastore removed from them upon dialing
completion this did not occur for the caller, causing it to have a
reference to itself that could go never go away (as it depended on
the destruction of the datastore which only happened when the channel
was destroyed). This resulted in the caller channel remaining on the
system despite it having hung up.
This change does the following to fix this issue:
1. The dial masquerade datastore is now removed from the caller upon
dialing completion, just like the dialed targets.
2. Upon destruction of the caller all the dialed targets are also
removed from the dial masquerade datastore (just in case).
3. The reference to the caller has been removed as it should not be
possible for the datastore to now be valid/useful after the lifetime
of the caller has ended.
ASTERISK-25025 #close
Change-Id: I1ef4ca5ca04980028604cc2af5d2992ac3431b3f
Renamed AST_VECTOR_INSERT to AST_VECTOR_REPLACE because it really
does replace not insert. The few users of AST_VECTOR_INSERT were
refactored. Because these are macros, there should be no ABI
compatibility issues.
Added AST_VECTOR_INSERT_AT that actually inserts an element into the
vector at a specific index pushing existing elements to the right.
Added AST_VECTOR_GET_CMP that can retrieve from the vector based
on a user-provided compare function.
Added AST_VECTOR_CALLBACK function that will execute a function
for each element in the vector. Similar to ao2_callback and
ao2_callback_data functions although the vector callback can take
a variable number of arguments. This should allow easy migration
to a vector where a container might be too heavy.
Added read/write locked vector and lock manipulation macros.
Added unit tests.
ASTERISK-25045 #close
Change-Id: I2e07ecc709d2f5f91bcab8904e5e9340609b00e0
This adds a test that will fail if any test failed to register. Also fail
if any test registration produced a warning about missing a leading or
trailing slash.
ASTERISK-25053 #close
Reported by: Corey Farrell
Change-Id: I93e50b8fcbcfa7f1f5b41b2c44a51685c09529c3
Format interfaces cannot be unregistered, so the modules that provide them
need to be held open except by shutdown.
ASTERISK-25054 #close
Reported by: Corey Farrell
Change-Id: Iadbd9675bf0d30b8fded5a739b163db3ea2db8f3
When using the force black background command-line option or configuration
option an invalid reset sequence is sent following a coloured output item
in the CLI, the result is that the colour is not 'turned off' and continues
until the next non-default coloured text output.
A reset sequence is already defined in term.c, but the ast_term_reset
function doesn't use it, instead building it's own invalid sequence and
returning that.
This patch changes that behaviour, removing the building of a reset sequence
and instead using the pre-built constant 'enddata' which is a suitable reset
sequence for this purpose.
ASTERISK-24896 #close
Reported by: Dan Tucny
Change-Id: I56323899123ae3264900389cae1f5b252aa3bf43
A few cases exist where headers of optional_api provders are included but
not needed. This causes unneeded calls to ast_optional_api_use.
* Don't include optional_api.h from sip_api.h.
* Move 'struct ast_channel_monitor' to channel.h.
* Don't include monitor.h from chan_sip.c, channel.c or features.c.
The move of struct ast_channel_monitor is needed since channel.c depends on
it. This has no effect on users of monitor.h since channel.h is included
from monitor.h.
ASTERISK-25051 #close
Reported by: Corey Farrell
Change-Id: I53ea65a9fc9693c89f8bcfd6120649bfcfbc3478
This ensures that refdebug is initialized before AO2_DEBUG if
both are enabled, since AO2_DEBUG allocates a container.
This change also makes AO2_DEBUG initialization critical, a
failure will abort Asterisk startup. This is needed since
the failure would be caused by reg_containers allocation
failure, and that would result in a segmentation fault by
ao2_container_register later in startup.
ASTERISK-25048 #close
Reported by: Corey Farrell
Change-Id: I9a243ea3fc5653b48b931ba6d61971cb2e530244
The PBX core maintains two hash tables for hints: a container of the
actual hints (hints), along with a container of devices that are watching that
hint (hintdevices). When a dialplan reload occurs, each hint in the hints
container is destroyed; this requires a lookup in the container of devices to
find the device => hint mapping object. In the current code, this performs an
ao2_callback, iterating over each of the device to hint objects in the
hintdevices container. For a large number of hints, this is extremely
expensive: dialplan reloads with 20000 hints could take several minutes
in just this phase.
This patch improves the performance of this step in the dialplan reloads
by caching which devices are watching a hint on the hint object itself.
Since we don't want to create a circular reference, we just cache the
name of the device. This allows us to perform a smarter ao2_callback on
the hintdevices container during hint removal, hashing on the name of the
device and returning an iterator to the matching names. The overall
performance improvement is rather large, taking this step down to a number of
seconds as opposed to minutes.
In addition, this patch also registers the hint containers in the PBX
core with the astobj2 library. This allows for reasonable debugging to
hash collisions in those containers.
ASTERISK-25040 #close
Reported by: Matt Jordan
Change-Id: Iedfc97a69d21070c50fca42275d7b3e714e59360
Scenario:
Alice calls Bob. Bob performs a blond transfer to Carol. Carol rejects
the incoming call (or some other immediate circumstance causes Carol not
to answer the call)
What occurs in this case is that when the bridge between Alice and Bob
breaks, Alice is told to masquerade into Bob's channel that had placed
the call to Carol. The actual masquerade goes down without a hitch.
However, a channel fixup callback that attempts to publish dial events
over Stasis has a crash. The reason for this crash is that the datastore
on Bob's channel that placed the outbound call to Carol only had a bare
pointer to Carol's channel. Since Carol rejected the incoming call,
Carol's channel has been hung up and freed, meaning accessing her
channel results in a crash.
The fix here is simple. The dial fixup code has been altered to hold
references to the involved channels and to drop those references when
freeing data.
ASTERISK-25025 #close
Reported by Chet Stevens
Change-Id: I54eedda207b8ec7a69263353b43abe5746aea197
The patch in 0b6410c4f8 did correctly fix a memory leak of the DTLS
structures in the RTP engine. However, when a 'core reload' is issued, a
double free of the memory pointed to by the char *'s in the DTLS
configuration struct can occur, as ast_rtp_dtls_cfg_free does not set
the pointers to NULL when they are freed.
This patch sets those pointers to NULL, preventing a second call to
ast_rtp_dtls_cfg_free from corrupting memory.
ASTERISK-25022
Change-Id: I820471e6070a37e3c26f760118c86770e12f6115
ao2 ref leak in res_rtp_asterisk.c when a DTLS policy is created.
The resources are linked into a table, but the original alloc refs
are never released. ast_strdup leak in rtp_engine.c. If
ast_rtp_dtls_cfg_copy() is called twice on the same destination struct,
a pointer to an alloc'd string is overwritten before the string is free'd.
ASTERISK-25022
Reported by: one47
Change-Id: I62a8ceb8679709f6c3769136dc6aa9a68202ff9b
clang can warn about a so called tautological-compare, when it finds
comparisons which are logically always true, and are therefor deemed
unnecessary.
Exanple:
unsigned int x = 4;
if (x > 0) // x is always going to be bigger than 0
Enum Case:
Each enumeration is its own type. Enums are an integer type but they
do not have to be *signed*. C leaves it up to the compiler as an
implementation option what to consider the integer type of a particu-
lar enumeration is. Gcc treats an enum without negative values as
an int while clang treats this enum as an unsigned int.
rmudgett & mmichelson: cast the enum to (unsigned int) in assert.
The cast does have an effect. For gcc, which seems to treat all enums
as int, the cast to unsigned int will eliminate the possibility of
negative values being allowed. For clang, which seems to treat enums
without any negative members as unsigned int, the cast will have no
effect. If for some reason in the future a negative value is ever
added to the enum the assert will still catch the negative value.
ASTERISK-24917
Change-Id: I0557ae0154a0b7de68883848a609309cdf0aee6a
__adjust_lock doesn't check for invalid objects, and doesn't have an
appropriate return value for invalid objects. Most callers of
__adjust_lock pass objects that have already been confirmed valid,
this change adds checks before the remaining calls.
ASTERISK-24997 #close
Reported by: Corey Farrell
Change-Id: I669100f87937cc3f867cec56a27ae9c01292908f
Fix a crash that could occur in __ast_channel_internal_alloc if
ao2_alloc fails.
ASTERISK-24991 #close
Change-Id: I4ca89189eb22f907408cb87d0a1645cfe1314a90
When a PBX registrar is unloaded, it will fail to remove its extension from
the context root_table if a dialplan application used by that extension is
still loaded. This can be the case for AGI, which can be unloaded after several
of the standard PBX providers. Often, this is harmless; however, if the
extension's priorities are removed during the failed unloading *and* the
dialplan application later unregisters, it leaves a ticking timebomb for the
next PBX provider that attempts to iterate over the extensions. When that
occurs, the peer_table pointer on the extension will already be set to NULL.
The current code does not check to see if the pointer is NULL before passing
it to a hashtab function this is not NULL tolerant.
Since it is possible for the peer_table to be NULL when we normally would not
expect that to be the case, the solution in this patch is to simply skip over
processing an extension's priorities if peer_table is NULL.
Prior to this patch, the tests/pbx/callerid_match test would crash during
module unload. With this patch, the test no longer crashes after running.
ASTERISK-24774 #close
Reported by: Corey Farrell
Change-Id: I2bbeecb7e0f77bac303a1b9135e4cdb4db6d4c40
A potential problem that can arise is the following:
* Bob's phone is programmed to automatically forward to Carol.
* Carol's phone is programmed to automatically forward to Bob.
* Alice calls Bob.
If left unchecked, this results in an endless loops of call forwards
that would eventually result in some sort of fiery crash.
Asterisk's method of solving this issue was to track which interfaces
had been dialed. If a destination were dialed a second time, then
the attempt to call that destination would fail since a loop was
detected.
The problem with this method is that call forwarding has evolved. Some
SIP phones allow for a user to manually forward an incoming call to an
ad-hoc destination. This can mean that:
* There are legitimate use cases where a device may be dialed multiple
times, or
* There can be human error when forwarding calls.
This change removes the old method of detecting forwarding loops in
favor of keeping a count of the number of destinations a channel has
dialed on a particular branch of a call. If the number exceeds the
set number of max forwards, then the call fails. This approach has
the following advantages over the old:
* It is much simpler.
* It can detect loops involving local channels.
* It is user configurable.
The only disadvantage it has is that in the case where there is a
legitimate forwarding loop present, it takes longer to detect it.
However, the forwarding loop is still properly detected and the
call is cleaned up as it should be.
Address review feedback on gerrit.
* Correct "mfgium" to "Digium"
* Decrement max forwards by one in the case where allocation of the
max forwards datastore is required.
* Remove irrelevant code change from pjsip_global_headers.c
ASTERISK-24958 #close
Change-Id: Ia7e4b7cd3bccfbd34d9a859838356931bba56c23
This is the second follow-on to https://reviewboard.asterisk.org/r/4572/ and the
discussion at
http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html
The basic issues are that changes in contact status don't cause events to be
emitted for the associated endpoint. Only dynamic contact add/delete actions
update the endpoint. Also, the qualify timeout is fixed by pjsip at 32 seconds
which is a long time.
This patch makes use of the new transaction timeout feature in r4585 and
provides the following capabilities...
1. A new aor/contact variable 'qualify_timeout' has been added that allows the
user to specify the maximum time in milliseconds to wait for a response to an
OPTIONS message. The default is 3000ms. When the timer expires, the contact is
marked unavailable.
2. Contact status changes are now propagated up to the endpoint as follows...
When any contact is 'Available', the endpoint is marked as 'Reachable'. When
all contacts are 'Unavailable', the endpoint is marked as 'Unreachable'. The
existing endpoint events are generated appropriately.
ASTERISK-24863 #close
Change-Id: Id0ce0528e58014da1324856ea537e7765466044a
Tested-by: Dmitriy Serov
Tested-by: George Joseph <george.joseph@fairview5.com>
Due to a race condition there was a chance that during an attended transfer the
channel's application would return NULL. This, of course, would cause a crash
when attempting to access the memory. This patch retrieves the channel's app
at an earlier time in processing in hopes that the app name is available.
However, if it is not then "unknown" is used instead. Since some string value
is now always present the crash can no longer occur.
ASTERISK-24869 #close
Reported by: viniciusfontes
Review:
Change-Id: I5134b84c4524906d8148817719d76ffb306488ac
Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file.
As a result, this patch removes Asterisk's support for showing source file
versions.
Specifically, it does the following:
* main/asterisk:
- Refactor the file_version structure to reflect that it no longer
tracks a version field.
- Alter the "core show file version" CLI command such that it always
reports the version of Asterisk. The file version is no longer
available.
* main/manager: The Version key now always reports the Asterisk version.
* UPGRADE: Add notes for:
- Modification to the ModuleCheck AMI Action.
- Modification of the "core show file version" CLI command.
Change-Id: Ia932d3c64cd18a14a3c894109baa657ec0a85d28
Add the .gitignore and .gitreview files to the asterisk repo.
NB: You can add local ignores to the .git/info/exclude file
without having to do a commit.
Common ignore patterns are in the top-level .gitignore file.
Subdirectory-specific ignore patterns are in their own .gitignore
files.
Change-Id: I4c8af3b8e3739957db545f7368ac53f38e99f696
Tested-by: George Joseph
With this patch, chan_pjsip/res_pjsip now sets the native formats to the
codecs negotiated by a call.
* The changes in chan_pjsip.c and res_pjsip_sdp_rtp.c set the native
formats to include all the negotiated audio codecs instead of only the
initial preferred audio codec and later the currently received audio
codec.
* The audio frame handling in channel.c:ast_read() is more streamlined and
will automatically adjust to changes in received frame formats. The new
policy is to remove translation and pass the new frame format to the
receiver except if the translation was to a signed linear format. A more
long winded version is commented in ast_read() along with some caveats.
* The audio frame handling in channel.c:ast_write() is more streamlined
and will automatically adjust any needed translation to changes in the
frame formats sent. Frame formats sent can change for many reasons such
as a recording is being played back or the bridged peer changed the format
it sends. Since it is a normal expectation that sent formats can change,
the codec mismatch warning message is demoted to a debug message.
* Removed the short circuit check in
channel.c:ast_channel_make_compatible_helper(). Two party bridges need to
make channels compatible with each other. However, transfers and moving
channels among bridges can result in otherwise compatible channels having
sub-optimal translation paths if the make compatible check is short
circuited. A result of forcing the reevaluation of channel compatibility
is that the asterisk.conf:transcode_via_slin and codecs.conf:genericplc
options take effect consistently now. It is unfortunate that these two
options are enabled by default and negate some of the benefits to the
changes in channel.c:ast_read() by forcing translation through signed
linear on a two party bridge.
* Improved the softmix bridge technology to better control the translation
of frames to the bridge. All of the incoming translation is now normally
handled by ast_read() instead of splitting any translation steps between
ast_read() and the slin factory. If any frame comes in with an unexpected
format then the translation path in ast_read() is updated for the next
frame and the slin factory handles the current frame translation.
This is the final patch in a series of patches aimed at improving
translation path choices. The other patches are on the following reviews:
https://reviewboard.asterisk.org/r/4600/https://reviewboard.asterisk.org/r/4605/
ASTERISK-24841 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4609/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434671 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds support for automatically detecting the type of DTMF that a
PJSIP endpoint supports. When the 'dtmf_mode' endpoint option is set to 'auto',
the channel created for an endpoint will attempt to determine if RFC 4733
DTMF is supported. If so, it will use that DTMF type. If not, the DTMF type
for the channel will be set to inband.
Review: https://reviewboard.asterisk.org/r/4438
ASTERISK-24706 #close
Reported by: yaron nahum
patches:
yaron_patch_3_Feb.diff submitted by yaron nahum (License 6676)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Given a source capability of h264 and ulaw, a destination capability of
h264 and g722 then ast_translator_best_choice() would pick h264 as the
best choice even though h264 is a video codec and Asterisk only supports
translation of audio codecs. When the audio starts flowing, there are
warnings about a codec mismatch when the channel tries to write a frame to
the peer.
* Made ast_translator_best_choice() only select audio codecs.
* Restore a check in channel.c:set_format() lost after v1.8 to prevent
trying to set a non-audio codec.
This is an intermediate patch for a series of patches aimed at improving
translation path choices for ASTERISK-24841.
This patch is a complete enough fix for ASTERISK-21777 as the v11 version
of ast_translator_best_choice() does the same thing. However, chan_sip.c
still somehow tries to call ast_codec_choose() which then calls
ast_best_codec() with a capability set that doesn't contain any audio
formats for the incoming call. The remaining warning message seems to be
a benign transient.
ASTERISK-21777 #close
Reported by: Nick Ruggles
ASTERISK-24380 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4605/
........
Merged revisions 434614 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434615 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Until we have a true module management facility it's sometimes necessary for one
module to force a reload on another before its own load is complete. If
Asterisk isn't fully booted yet, these reloads are deferred. The problem is
that asterisk reports fully booted before processing the deferred reloads which
means Asterisk really isn't quite ready when it says it is.
This patch moves the report of fully booted after the processing of the deferred
reloads is complete.
Since the pjsip stack has the most number of related modules, I ran the
channels/pjsip testsuite to make sure there aren't any issues. All tests
passed.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4604/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434544 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes autological comparison warnings in the following:
* chan_skinny: letohl may return a signed or unsigned value, depending on the
macro chosen
* func_curl: Provide a specific cast to CURLoption to prevent mismatch
* cel: Fix enum comparisons where the enum can never be negative
* enum: Fix comparison of return result of dn_expand, which returns a signed
int value
* event: Fix enum comparisons where the enum can never be negative
* indications: tone_data.freq1 and freq2 are unsigned, and hence can never be
negative
* presencestate: Use the actual enum value for INVALID state
* security_events: Fix enum comparisons where the enum can never be negative
* udptl: Don't bother to check if the return value from encode_length is less
than 0, as it returns an unsigned int
* translate: Since the parameters are unsigned int, don't bother checking
to see if they are negative. The cast to unsigned int would already blow
past the matrix bounds.
* res_pjsip_exten_state: Use a temporary value to cache the return of
ast_hint_presence_state
* res_stasis_playback: Fix enum comparisons where the enum can never be
negative
* res_stasis_recording: Add an enum value for the case where the recording
operation is in error; fix enum comparisons
* resource_bridges: Use enum value as opposed to -1
* resource_channels: Use enum value as opposed to -1
Review: https://reviewboard.asterisk.org/r/4533
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4533.patch submitted by dkdegroot (License 6600)
........
Merged revisions 434469 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434470 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a channel enters the bridging system it is first made compatible with
the bridge and then the bridge technology makes the channel compatible
with the technology. For all but the DAHDI native and softmix bridge
technologies the make channel compatible with the bridge step is an
effective noop because the other technologies allow all audio formats.
For the DAHDI native bridge technology it doesn't matter because it is not
an initial bridge technology and chan_dahdi allows only one native format
per channel. For the softmix bridge technology, it is a noop at best and
harmful at worst because the wrong translation path could be setup if the
channel's native formats allow more than one audio format.
This is an intermediate patch for a series of patches aimed at improving
translation path choices.
* Removed code dealing with the unnecessary step of making the channel
compatible with the bridge.
ASTERISK-24841
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4600/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434424 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When registering to a SIP server with TLS, Asterisk will accept CA signed
certificates with a common name that was signed for a domain other than the
one requested if it contains a null character in the common name portion of
the cert. This patch fixes that by checking that the common name length
matches the the length of the content we actually read from the common name
segment. Some certificate authorities automatically sign CA requests when
the requesting CN isn't already taken, so an attacker could potentially
register a CN with something like www.google.com\x00www.secretlyevil.net
and have their certificate signed and Asterisk would accept that certificate
as though it had been for www.google.com - this is a security fix and is
noted in AST-2015-003.
ASTERISK-24847 #close
Reported by: Maciej Szmigiero
Patches:
asterisk-null-in-cn.patch submitted by mhej (license 6085)
........
Merged revisions 434337 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 434338 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After completing an attended transfer the transfer target channel (the one that
gets swapped out) was not being hung up after leaving the bridge. This resulted
in a channel possibly being left around. Added an explicit softhangup for the
channel in question after the transfer is successfully completed in order to
make sure the channel is hung up.
ASTERISK-24782 #close
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4575/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For some applications - such as SLA - a phone pressing hold should not behave
in the fashion that the Asterisk core would like it to. Instead, the hold
action has some application specific behaviour associated with it - such as
disconnecting the channel that initiated the hold; only playing MoH to channels
in the bridge if the channels are of a particular type, etc.
One way of accomplishing this is to use a framehook to intercept the
hold/unhold frames, raise an event, and eat the frame. Tasty. This patch
accomplishes that using a new dialplan function, HOLD_INTERCEPT.
In addition, some general cleanup of raising hold/unhold Stasis messages was
done, including removing some RAII_VAR usage.
Review: https://reviewboard.asterisk.org/r/4549/
ASTERISK-24922 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These are fixes for compilation under gcc 5.0...
chan_sip.c: In parse_request needed to make 'lim' unsigned.
inline_api.h: Needed to add a check for '__GNUC_STDC_INLINE__' to detect C99
inline semantics (same as clang).
ccss.c: In ast_cc_set_parm, needed to fix weird comparison.
dsp.c: Needed to work around a possible compiler bug. It was throwing
an array-bounds error but neither
sgriepentrog, rmudgett nor I could figure out why.
manager.c: In action_atxfer, needed to correct an array allocation.
This patch will go to 11, 13, trunk.
Review: https://reviewboard.asterisk.org/r/4581/
Reported-by: Jeffrey Ollie
Tested-by: George Joseph
ASTERISK-24932 #close
........
Merged revisions 434113 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434114 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes an invalid format specifier used in the formatting of an
ERROR message in the framehook code. The format specifier specifies a
type of 'unsigned short', but the argument passed to it is of type 'int'.
The patch changes the format specifier to 'i'.
Review: https://reviewboard.asterisk.org/r/4540
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4535.patch submitted by dkdegroot (License 6600)
........
Merged revisions 434087 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434088 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Versions of Asterisk prior to 12 defaulted to 8000 as a sample rate
if one was not provided by a format. In Asterisk 13, this was removed.
The result was that some calculations which involve dividing by the
sample rate resulted in dividing by 0. The fix being put in place
here is to have the same default fallback that was present in previous
versions of Asterisk.
Asterisk-24914 #close
Reported by Marcello Ceschia
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434046 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes some invalid enum conversion warnings caught by clang. In
particular:
* chan_sip: Several functions mixed usage of the st_refresher_param
enum and st_refresher enum. This patch corrects the functions to use the
right enum.
* chan_pjsip: Fixed mixed usage of ast_sip_session_t38state and ast_t38_state.
* strings: Fixed incorrect usage of AO2 flags with strings container.
* res_stasis: Change a return enumeration to stasis_app_user_event_res.
Review: https://reviewboard.asterisk.org/r/4535
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4535.patch submitted by dkdegroot (License 6600)
........
Merged revisions 433746 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433747 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The patch in r433720 caused a warning to be kicked back by gcc. It occurred
due to this check in unistd.h:
if (__nbytes > __bos0 (__buf))
return __read_chk_warn (__fd, __buf, __nbytes, __bos0 (__buf));
That is, if __nbytes is greater than the result of GCC's built-in object size
for the struct, we'll kick back a warning.
As it turns out, this is because there is an error in the code in the patch.
We are passing the address of the pointer to the struct, not iev, which is a
pointer to the struct. Hence, the number of bytes is probably going to be lot
larger than the number of bytes that make up a pointer! This patch changes
the code just read from the pointer to the struct - which fixes the warning.
ASTERISK-24917
........
Merged revisions 433743 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433744 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes a warning caught by clang, wherein a variable sized struct is
not located at the end of a struct. While the code in question actually
expected this, this is a good warning to watch for. Hence, this patch refactors
the code in question to not have two variable length elements in the same
struct.
Review: https://reviewboard.asterisk.org/r/4530/
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4530.patch submitted by dkdegroot (License 6600)
........
Merged revisions 433717 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This introduces a new logger routine ast_log_safe. This routine should be
used for all error messages in code that can be run as a result of ast_log.
ast_log_safe does nothing if run recursively. All error logging in
astobj2.c, strings.c and utils.h have been switched to ast_log_safe.
This required adding support for raw threadstorage. This provides direct
access to the void* pointer in threadstorage. In ast_log_safe, NULL is used
to signify that this thread is not already running ast_log_safe, (void*)1 when
it is already running. This was done since it's critical that ast_log_safe
do nothing that could log during recursion checking.
ASTERISK-24155 #close
Reported by: Timo Teräs
Review: https://reviewboard.asterisk.org/r/4502/
........
Merged revisions 433522 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433523 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since 'core stop now' and 'core restart now' do not stop modules,
it is unsafe for most of the core to run cleanups. Originally all
cleanups used ast_register_atexit, and were only changed when it
was shown to be unsafe. ast_register_atexit is now used only when
absolutely required to prevent corruption and close child processes.
Exceptions that need to use ast_register_atexit:
* CDR: Flush records.
* res_musiconhold: Kill external applications.
* AstDB: Close the DB.
* canary_exit: Kill canary process.
ASTERISK-24142 #close
Reported by: David Brillert
ASTERISK-24683 #close
Reported by: Peter Katzmann
ASTERISK-24805 #close
Reported by: Badalian Vyacheslav
ASTERISK-24881 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4500/
Review: https://reviewboard.asterisk.org/r/4501/
........
Merged revisions 433495 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Attempting to execute DTMF in a confbridge while file playback (prompt,
announcement, etc) is occurring is not allowed. You have to wait until
the sound file has completed before entering DTMF. This patch fixes it
so that app_confbridge now monitors for dtmf key presses during menu
driven file playback. If a key is pressed playback stops and it executes
the matched menu option.
ASTERISK-24864 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4510/
........
Merged revisions 433445 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433446 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* In res/res_sorcery_realtime.c: Broke long line.
* In main/bucket.c: Eliminated unnecessary NULL check as
ast_sorcery_unref() is NULL tolerant and set the global object to NULL
after unref in the system shutdown bucket_cleanup().
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433420 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses compilation issues for OpenBSD. Specifically, it
addresses:
* It allows including <sys/vmmeter.h> in asterisk.c
* Provides a needed (size_t) cast in xmldoc.c
In 13+, it also addresses a conditional inclusion in loader.c.
Review: https://reviewboard.asterisk.org/r/4506
ASTERISK-24880 #close
Reported by: snuffy
Tested by: snuffy
patches:
misc-openbsd.diff uploaded by snuffy (License 5024)
........
Merged revisions 433245 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433247 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valgrind found a memory leak and invalid access.
* Fix invalid access by sscanf() being fed a non-nul terminated string of
digits in res/res_pjsip_sdp_rtp.c:get_codecs().
* Fix memory leak in main/sorcery.c:sorcery_object_field_destructor().
* Fix potential NULL pointer dereference in
main/xmldoc.c:xmldoc_get_syntax_config_option().
Review: https://reviewboard.asterisk.org/r/4513/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433199 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valgrind found some memory leaks associated with ast_sockaddr_resolve().
Most of the leaks had already been fixed by earlier memory leak hunt
patches. This patch performs an audit of ast_sockaddr_resolve() and found
one more.
* Fix ast_sockaddr_resolve() memory leak in
apps/app_externalivr.c:app_exec().
* Made main/netsock2.c:ast_sockaddr_resolve() always set the addrs
parameter for safety so the pointer will never be uninitialized on return.
The same goes for res/res_pjsip_acl.c:extract_contact_addr().
* Made functions that call ast_sockaddr_resolve() with RAII_VAR()
controlling the addrs variable use ast_free instead of ast_free_ptr to
provide better MALLOC_DEBUG information.
Review: https://reviewboard.asterisk.org/r/4509/
........
Merged revisions 433056 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433057 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In realtime, it is normal to have a database with both 'allow' and 'disallow'
columns in the schema. It is perfectly valid to have an 'allow' value of
'!all,g722,ulaw,alaw' and no 'disallow' value. Unlike in static conf files,
you can't *not* provide the disallow value. Thus, the empty disallow value
causes a spurious WARNING message, which is kind of annoying.
This patch makes it so that a 'disallow' value with no ... value ... is
ignored. Granted, you can still screw this up as well, as technically
specifying 'disallow=all,!ulaw' allows only ulaw, and then you would have no
'allow' value in your database. But really, why would you do that? WHY?
ASTERISK-16779 #close
Reported by: Atis Lezdins
........
Merged revisions 432970 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432971 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "core set debug channel" CLI command mistakenly had source filenames
added to its tab completion. This occurred because the CLI generator fell back
to the "core set debug" command which permits setting debug at a source
filename level.
ASTERISK-21038 #close
Reported by: Richard Kenner
........
Merged revisions 432944 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an audiohook is created (which is used by the various Spy applications
and Snoop channel in Asterisk 13+), it initially is given a sample rate of
8kHz. It is expected, however, that this rate may change based on the media
that passes through the audiohook. However, the read/write operations on the
audiohook behave very differently.
When a frame is written to the audiohook, the format of the frame is checked
against the internal sample rate. If the rate of the format does not match
the internal sample rate, the internal sample rate is updated and a new SLIN
format is chosen based on that sample rate. This works just fine.
When a frame is read, however, we do something quite different. If the format
rate matches the internal sample rate, all is fine. However, if the rates
don't match, the audiohook attempts to "fix up" the number of samples that
were requested. This can result in some seriously large number of samples
being requested from the read/write factories.
Consider the worst case - 192kHz SLIN. If we attempt to read 20ms worth of
audio produced at that rate, we'd request 3840 samples (192000 / (1000 / 20)).
However, if the audiohook is still expecting an internal sample rate of 8000,
we'll attempt to "fix up" the requested samples to:
samples_converted = samples * (ast_format_get_sample_rate(format) /
(float) audiohook->hook_internal_samp_rate);
which is:
92160 = 3840 * (192000 / 8000)
This results in us attempting to read 92160 samples from our factories, as
opposed to the 3840 that we actually wanted. On a 64-bit machine, this
miraculously survives - despite allocating up to two buffers of length 92160
on the stack. The 32-bit machines aren't quite so lucky. Even in the case where
this works, we will either (a) get way more samples than we wanted; or (b) get
about 3840 samples, assuming the timing is pretty good on the machine.
Either way, the calculation being performed is wrong, based on the API users
expectations.
My first inclination was to allocate the buffers on the heap. As it is,
however, there's at least two drawbacks with doing this:
(1) It's a bit complicated, as the size of the buffers may change during the
lifetime of the audiohook (ew).
(2) The stack is faster (yay); the heap is slower (boo).
Since our calculation is flat out wrong in the first place, this patch fixes
this issue by instead updating the internal sample rate based on the format
passed into the read operation. This causes us to read the correct number of
samples, and has the added benefit of setting the audihook with the right
SLIN format.
Note that this issue was caught by the Asterisk Test Suite as a result of
r432195 in the 13 branch. Because this issue is also theoretically possible
in Asterisk 11, the change is being made here as well.
Review: https://reviewboard.asterisk.org/r/4475/
........
Merged revisions 432810 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432811 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RAII_VAR, which is used extensively in Asterisk to manage reference counted
resources, uses a GCC extension to automatically invoke a cleanup function
when a variable loses scope. While this functionality is incredibly useful
and has prevented a large number of memory leaks, it also prevents Asterisk
from being compiled with clang.
This patch updates the RAII_VAR macro such that it can be compiled with clang.
It makes use of the BlocksRuntime, which allows for a closure to be created
that performs the actual cleanup.
Note that this does not attempt to address the numerous warnings that the clang
compiler catches in Asterisk.
Much thanks for this patch goes to:
* The folks on StackOverflow who asked this question and Leushenko for
providing the answer that formed the basis of this code:
http://stackoverflow.com/questions/24959440/rewrite-gcc-cleanup-macro-with-nested-function-for-clang
* Diederik de Groot, who has been extremely patient in working on getting this
patch into Asterisk.
Review: https://reviewboard.asterisk.org/r/4370/
ASTERISK-24133
ASTERISK-23666
ASTERISK-20399
ASTERISK-20850 #close
Reported by: Diederik de Groot
patches:
RAII_CLANG.patch uploaded by Diederik de Groot (License 6600)
........
Merged revisions 432807 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432808 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The localtime management in the Asterisk core contains a thread that watches
for changes in the local timezone. On systems where the directory containing
/etc/localtime is modified frequently, the thread monitoring the changes will
be woken up to determine if any changes in timezone have occurred. When using
kqueue(2), this can cause a leak of file descriptors due to some improper
management of resources.
This patch updates the kqueue(2) handling in localtime, such that is no longer
leaks resources.
Review: https://reviewboard.asterisk.org/r/4450/
ASTERISK-24739 #close
Reported by: Ed Hynan
patches:
11.15.0-u.diff uploaded by Ed Hynan (Licnese 6680)
11.7.0-u.diff uploaded by Ed Hynan (License 6680)
svn-trunk-Jan-26-2015-u.diff uploaded by Ed Hynan (License 6680)
........
Merged revisions 432691 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432693 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a 'core restart now' or 'core stop now' is executed and a channel is
currently in a media operation, the translator matrix can be destroyed while a
channel is currently blocked on getting the best translation choice
(see ast_translator_best_choice). When the channel gets the mutex, the
translation matrix now has invalid memory, and Asterisk crashes.
This patch does two things:
(1) We now only clean up the translation matrix on a graceful shutdown. In that
case, there are no channels, and so there is no risk of this occurring.
(2) We also now set the __matrix and __indextable to NULL. In some initial
backtraces when this occurred, it looked as if there was a memory corruption
occurring, and it wasn't until we determined that something had restarted
Asterisk that the issue became clear. By setting these to NULL on shutdown,
it becomes a bit easier to determine why a crash is occurring.
Note that we could litter the code with NULL checks on the __matrix, but the
act of making the translation matrix cleaned up on shutdown should preclude
this issue from occurring in the first place, and this part of the code needs
to be as fast as possible.
Review: https://reviewboard.asterisk.org/r/4457/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432453 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Sending the following ARI commands caused Asterisk to crash if the JSON
body 'variables' object passes values of types other than strings.
POST /ari/channels
POST /ari/channels/{channelid}
PUT /ari/endpoints/sendMessage
PUT /ari/endpoints/{tech}/{resource}/sendMessage
* Eliminated RAII_VAR usage in ast_ari_channels_originate_with_id(),
ast_ari_channels_originate(), ast_ari_endpoints_send_message(), and
ast_ari_endpoints_send_message_to_endpoint().
ASTERISK-24751 #close
Reported by: jeffrey putnam
Review: https://reviewboard.asterisk.org/r/4447/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432404 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a self-destruction option to the
dial api. The usefulness of this is mostly when
using async mode to spawn a separate thread used
to handle the new call, while the calling thread
is allowed to go on about other business.
The only alternative to this option would be the
calling thread spawning a new thread, or hanging
around itself waiting to destroy the dial struct
after completion.
Example of use (minus error checking):
struct ast_dial *dial = ast_dial_create();
ast_dial_append(dial, "PJSIP", "200", NULL);
ast_dial_option_global_enable(dial, AST_DIAL_OPTION_ANSWER_EXEC, "Echo");
ast_dial_option_global_enable(dial, AST_DIAL_OPTION_SELF_DESTROY, NULL);
ast_dial_run(dial, NULL, 1);
The dial_run call will return almost immediately
after spawning the new thread to run and monitor
the dial. If the call is answered, it is placed
into the echo app. When completed, it will call
ast_dial_destroy() on the dial structure.
Note that any allocations made to pass values to
ast_dial_set_user_data() or dial options must be
free'd in a state callback function on any of:
AST_DIAL_RESULT_UNASWERED,
AST_DIAL_RESULT_ANSWERED,
AST_DIAL_RESULT_HANGUP, or
AST_DIAL_RESULT_TIMEOUT.
Review: https://reviewboard.asterisk.org/r/4443/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Kevin Harwell
David M. Lee
George Joseph
Joshua Colp
Ivan Poddubny
Corey Farrell
Matt Jordan
Corey Edwards
snuffy
Jonathan Rose
Rodrigo Ramírez Norambuena
Alexander Traud
Richard Mudgett
D Tucny
Mark Michelson
Steve Davies
Diederik de Groot
Scott Griepentrog