| Age | Commit message (Collapse) | Author |
|---|
|
* say.c Changed 'digits/and' to 'vm-and' for en_GB
ASTERISK-26598 #close
Change-Id: If1b713e5daea6f952b339f139178d292a6c4fcfe
|
|
* manager.c:manager_state_cb() Fix potential use of uninitialized hint[]
if a hint does not exist for the requested extension. Ran into this when
developing a testsuite test. The AMI event ExtensionStatus came out with
the hint header value containing garbage. The AMI event PresenceStatus
also had the same issue.
* manager.c:action_extensionstate() no need to completely initialize the
hint[]. Only initialize the first element.
* pbx.c:ast_add_hint() Remove unnecessary assignment.
* chan_sip.c: Eliminate an unneeded hint[] local variable. We only care
about the return value of ast_get_hint() there.
Change-Id: Ia9a8786f01f93f1f917200f0a50bead0319af97b
|
|
... and clean them both up on uninstall.
We've fixed the issue where 'make install' was installing to
/usr/lib on 64-bit systems that use /usr/lib64. Now we need
to clean up the remnants in /usr/lib.
* 'make install' now prints a warning if DESTDIR/ASTLIBDIR
contains 'lib64' and libasterisk* shared libraries or modules
are also found in DESTDIR/ASTLIBDIR with 'lib64' transformed
to 'lib'.
* 'make uninstall' ALWAYS cleans up both DESTDIR/ASTLIBDIR and
DESTDIR/ASTLIBDIR with 'lib64' transformed to 'lib'.
ASTERISK-26705
Change-Id: I6edddeb3c07a51e7c7ba7cac3c05e4bf3ec3f01f
|
|
On some platforms a multiarch approach is used for libraries.
The build system does not take this into account and still
places libraries into the lib directory if no --libdir is
specified to configure. On initial startup this results in
libasteriskssl.so not being found, as it is not in the multiarch
lib directory. To make matters worse, options were being passed
to ldconfig on both Linux and FreeBSD that actually prevented
the rebuild of the cache.
* Fedora has a /usr/share/config.site that automatically tells
autoconf to use /usr/lib64 but CentOS does not. This logic was
copied to configure.ac and modified so systems like Ubuntu,
which still use /usr/lib for 64-bit systems, aren't affected.
Now that we have them in the correct directory...
In order for the system loader to find libasteriskssl and
libasteriskpj, one of 3 things has to happen...
- The linker cache must be rebuilt including the directory
where the libasterisk* libraries were installed. Only root
can rebuild the cache. This was busted.
- We have to link the asterisk binary with an rpath pointing
to the directrory where the libasterisk* libraries were
installed. This makes things very complicated and will happen
over the collective dead bodies of everyone who's had to
package a distribution with an rpath.
- Finally, you can start asterisk with LD_LIBRARY_PATH set to the
directrory where the libasterisk* libraries were installed.
There are no other options. So...
* The invokation of ldconfig has been moved from main/Makefile
to ASTTOPDIR/Makefile, the options have been removed, and
DESTDIR/ASTLIBDIR appended. If you aren't root, you will be
warned after the "Asterisk Installation Compete" banner that
you must re-run 'make install' as root, manually run
'ldconfig DESTDIR/ASTLIBDIR' as root, or run asterisk with
LD_LIBRARY_PATH.
ASTERISK-26705
Change-Id: I2a64b7c33a7d3e9bde20f47e3d3ab771977af982
|
|
This reverts commit d90430953c508670a67de68de400fef44f5e9fba.
Change-Id: I758fe7ea0408f83a6df8e1774310d69f482700f6
|
|
On some platforms a multiarch approach is used for libraries.
The build system does not take this into account and still
places libraries into the lib directory if no --libdir is
specified to configure. On initial startup this results in
libasteriskssl.so not being found, as it is not in the multiarch
lib directory.
This change does the minimally invasive thing and executes
ldconfig so that the libraries in the lib directory are found
and their location cached. By doing so Asterisk starts up fine.
If DESTDIR is specified, however, the old logic is executed as
the install process may not have permission to alter the ldconfig
cache.
ASTERISK-26705
Change-Id: If4eca46ac510c6fea5568256280ffdb3888d7bb4
|
|
|
|
This reverts commit e910dbab90ef3d628955c49f441b2c9dda1f222c.
Change-Id: I242aa0a965a79738dc898299959c6d2e020c86bd
|
|
Change-Id: I0ddf01cd3c10d3b6666d7bf68d4e206a37f4fbdb
|
|
On some platforms a multiarch approach is used for libraries.
The build system does not take this into account and still
places libraries into the lib directory if no --libdir is
specified to configure. On initial startup this results in
libasteriskssl.so not being found, as it is not in the multiarch
lib directory.
This change does the minimally invasive thing and executes
ldconfig so that the libraries in the lib directory are found
and their location cached. By doing so Asterisk starts up fine.
ASTERISK-26705
Change-Id: I6d30b6427e9d5e69470e11327c7ff203fa7da519
|
|
ASTERISK-26794 #close
Change-Id: I9cbc3b6b6a8aab590f5ccde9c262a98e4d5253a1
|
|
OpenSSL 1.1 requires no explicit initialization. The hacks in the
library are not needed. They also happen to fail running Asterisk.
ASTERISK-26109 #close
Change-Id: I3b3efd5d80234a4c45a8ee58dcfe25b15d9ad100
|
|
OpenSSL 1.1 introduced TLS_client_method() and deprecated the previous
version-specific methods (such as TLSv1_client_method(). Other than
being simpler to use and more correct (gain support for TLS newer that
TLS1, in our case), the older ones produce a deprecation warning that
fails the build in dev-mode.
ASTERISK-26109 #close
Change-Id: I257b1c8afd09dcb0d96cda3a41cb9f7a15d0ba07
|
|
Use OPENSSL_VERSION_NUMBER instead of OPENSSL_API_COMPAT to detect
the openssl 1.1 API.
ASTERISK-26109 #close
Change-Id: I4e448f55ef516aedf6ad154037c35577a421a458
|
|
|
|
|
|
|
|
* app_minivm: Use built-in completion facilities to complete optional
arguments.
* app_voicemail: Use built-in completion facilities to complete
optional arguments.
* app_confbridge: Add missing colons after 'Usage' text.
* chan_alsa: Use built-in completion facilities to complete optional
arguments.
* chan_sip: Use built-in completion facilities to complete optional
arguments. Add completions for 'load' for 'sip show user', 'sip show
peer', and 'sip qualify peer.'
* chan_skinny: Correct and extend completions for 'skinny reset' and
'skinny show line.'
* func_odbc: Correct completions for 'odbc read' and 'odbc write'
* main/asterisk: Correct and extend completions for 'core show file
version.'
* main/astmm: Use built-in completion facilities to complete arguments
for 'memory' commands.
* main/bridge: Correct completions for 'bridge kick.'
* main/ccss: Use built-in completion facilities to complete arguments
for 'cc cancel' command.
* main/cli: Add 'all' completion for 'channel request hangup.' Correct
completions for 'core set debug channel.' Correct completions for 'core
show calls.'
* main/pbx_app: Remove redundant completions for 'core show
applications.'
* main/pbx_hangup_handler: Remove unused completions for 'core show
hanguphandlers all.'
* res_sorcery_memory_cache: Add completion for 'reload' argument of
'sorcery memory cache stale' and properly implement.
Change-Id: Iee58c7392f6fec34ad9d596109117af87697bbca
|
|
The ast_waitfor_nandfds operation will manipulate the flags
of channels passed in. This was previously done without
the channel lock being held. This could result in incorrect
values existing for the flags if another thread manipulated
the flags at the same time.
This change locks the channel during flag manipulation.
ASTERISK-26788
Change-Id: I2c5c8edec17c9bdad4a93291576838cb552ca5ed
|
|
In Asterisk 11, if the 'Originate' AMI command failed to connect the provided
Channel while in extension mode, a 'failed' extension would be looked up and
run. This was, I believe, unintentionally removed in 51b6c49. This patch
restores that behavior.
This also adds an enum for the various 'synchronous' modes in an attempt to
make them meaningful.
ASTERISK-26115 #close
Reported by: Nasir Iqbal
Change-Id: I8afbd06725e99610e02adb529137d4800c05345d
|
|
We shouldn't unlock the channel after starting a snapshot staging because
another thread may interfere and do its own snapshot staging.
* app_dial.c:dial_exec_full() made hold the channel lock while setting up
the outgoing channel staging. Made hold the channel lock after the called
party answers while updating the caller channel staging.
* chan_sip.c:sip_new() completed the channel staging on off-nominal exit.
Also we need to use ast_hangup() instead of ast_channel_unref() at that
location.
* channel.c:__ast_channel_alloc_ap() added a comment about not needing to
complete the channel snapshot staging on off-nominal exit paths.
* rtp_engine.c:ast_rtp_instance_set_stats_vars() made hold the channel
locks while staging the channels for the stats channel variables.
Change-Id: Iefb6336893163f6447bad65568722ad5d5d8212a
|
|
When performing an SRV lookup using the ast_srv_lookup function it
did not properly handle the situation where 0 records are returned.
If this happened it would wrongly assume that at least one record
was present.
This change fixes the code so it will exit early if an error occurs
or if 0 records are returned.
ASTERISK-26772
patches:
srv_lookup.patch submitted by nappsoft (license 6822)
Change-Id: I09b19081c74e0ad11c12bf54a257243b1bcb2351
|
|
|
|
into 13
|
|
|
|
If an audiohook is placed on a channel that does not require transcoding,
muting that hook will cause the underlying frames to be muted as well.
The original patch is from David Woolley but I have modified slightly.
ASTERISK-21094 #close
Reported by: David Woolley
Patches:
ASTERISK-21094-Patch-1.8-1.txt (license #5737) patch uploaded
by David Woolley
Change-Id: Ib2b68c6283e227cbeb5fa478b2d0f625dae338ed
|
|
Using the timerfd timing module can cause channel freezing, lingering, or
deadlock issues. The problem is because this is the only timing module
that uses an associated alert-pipe. When the alert-pipe becomes
unbalanced with respect to the number of frames in the read queue bad
things can happen. If the alert-pipe has fewer alerts queued than the
read queue then nothing might wake up the thread to handle received frames
from the channel driver. For local channels this is the only way to wake
up the thread to handle received frames. Being unbalanced in the other
direction is less of an issue as it will cause unnecessary reads into the
channel driver.
ASTERISK-26716 is an example of this deadlock which was indirectly fixed
by the change that found the need for this patch.
* In channel.c:__ast_queue_frame(): Adding frame lists to the read queue
did not add the same number of alerts to the alert-pipe. Correspondingly,
when there is an exceptionally long queue event, any removed frames did
not also remove the corresponding number of alerts from the alert-pipe.
ASTERISK-26632 #close
Change-Id: Ia98137c5bf6e9d6d202ce0eb36441851875863f6
|
|
A dialplan intercept routine is equivalent to an interrupt routine. As
such, the routine must be done quickly and you do not have access to the
media stream. These restrictions are necessary because the media stream
is the responsibility of some other code and interfering with or delaying
that processing is bad. A possible future dialplan processing
architecture change may allow the interception routine to run in a
different thread from the main thread handling the media and remove the
execution time restriction.
* Made res_agi.c:run_agi() running an AGI in an interception routine run
in DeadAGI mode. No touchy channel frames.
ASTERISK-25951
ASTERISK-26343
ASTERISK-26716
Change-Id: I638f147ca7a7f2590d7194a8ef4090eb191e4e43
|
|
There are several issues with deferring frames that are caused by the
refactoring.
1) The code deferring frames mishandles adding a deferred frame to the
deferred queue. As a result the deferred queue can only be one frame
long.
2) Deferrable frames can come directly from the channel driver as well as
the read queue. These frames need to be added to the deferred queue.
3) Whoever is deferring frames is really only doing the __ast_read() to
collect deferred frames and doesn't care about the returned frames except
to detect a hangup event. When frame deferral is completed we must make
the normal frame processing see the hangup as a frame anyway. As such,
there is no need to have varying hangup frame deferral methods. We also
need to be aware of the AST_SOFTHANGUP_ASYNCGOTO hangup that isn't real.
That fake hangup is to cause the PBX thread to break out of loops to go
execute a new dialplan location.
4) To properly deal with deferrable frames from the channel driver as
pointed out by (2) above, means that it is possible to process a dialplan
interception routine while frames are deferred because of the
AST_CONTROL_READ_ACTION control frame. Deferring frames is not
implemented as a re-entrant operation so you could have the unsupported
case of two sections of code thinking they have control of the media
stream.
A worse problem is because of the bad implementation of the AMI PlayDTMF
action. It can cause two threads to be deferring frames on the same
channel at the same time. (ASTERISK_25940)
* Rather than fix all these problems simply revert the API refactoring as
there is going to be only autoservice and safe_sleep deferring frames
anyway.
ASTERISK-26343
ASTERISK-26716 #close
Change-Id: I45069c779aa3a35b6c863f65245a6df2c7865496
|
|
|
|
|
|
|
|
The escalator works by creating a set of startup commands in cli.conf
that set up logger channels and issue the debug commands for the
subsystems specified. If asterisk is running when it is executed,
the same commands will be issued to the running instance. The original
cli.conf is saved before any changes are made and can be restored by
executing '$prog --reset'.
The log output will be stored in...
$astlogdir/message.$uniqueid
$astlogdir/debug.$uniqueid
$astlogdir/dtmf.$uniqueid
$astlogdir/fax.$uniqueid
$astlogdir/security.$uniqueid
$astlogdir/pjsip_history.$uniqueid
$astlogdir/sip_history.$uniqueid
Some minor tweaks were made to chan_sip, and res_pjsip_history
so their history output could be send to a log channel as packets
are captured.
A minor tweak was also made to manager so events are output to verbose
when "manager set debug on" is issued.
Change-Id: I799f8e5013b86dc5282961b27383d134bf09e543
|
|
Issue introduced in b59956a87. In the non-darwin case libastssl/pj
should be versioned. This causes the symbol file for this lib
to not be generated.
Change-Id: Ib07ae8c40252813c488e2c1ac6204fd42816dd4c
|
|
|
|
When a reading end of the network socket is closed by an AMI manager,
the EPIPE is signaled when writing to our end, resulting in the
spurious log error message
ast_careful_fwrite: fwrite() returned error: Broken pipe
Previously EPIPE was handled in ast_carefulwrite() a few lines above,
but not in this function.
ASTERISK-26753
Change-Id: I6a67335cd6526608bb9b78f796c626b1677664b8
|
|
|
|
|
|
|
|
|
|
* channel.c:ast_sendtext(): Fix T.140 SendText memory leak.
* format_compatibility.c: T.140 RED and T.140 were swapped.
* res_rtp_asterisk.c:rtp_red_init(): Fix ast_format_t140_red ref leak.
* res_rtp_asterisk.c:rtp_red_init(): Fix data race after starting periodic
scheduled red_write().
* res_rtp_asterisk.c: Some other minor misc tweaks.
Change-Id: Ifa27a2e0f8a966b1cf628607c86fc4374b0b88cb
|
|
Change-Id: I32e6a589cf9009450e4ff7cb85c07c9d9ef7fe4a
|
|
* make_silence() created a malloced silence slin frame without adding a
slin format ref. When the frame is destroyed it will unref the slin
format that never had a ref added. Memory corruption is expected to
follow.
* Simplified and fixed counting the number of samples in a frame list for
make_silence().
* Eliminated an unnecessary RAII_VAR associated with the make_silence()
frame.
Change-Id: I47de3f9b92635b7f8b4d72309444d6c0aee6f747
|
|
* ast_frisolate() could leak frame format refs on allocation
failures.
* Similified code in ast_frisolate() and code used by
ast_frisolate().
Change-Id: I79566d4d36b3d7801bf0c8294fcd3e9a86a2ed6d
|
|
The 'ari set debug' command has been enhanced to accept 'all' as an
application name. This allows dumping of all apps even if an app
hasn't registered yet. To accomplish this, a new global_debug global
variable was added to res/stasis/app.c and new APIs were added to
set and query the value.
'ari set debug' now displays requests and responses as well as events.
This required refactoring the existing debug code.
* The implementation for 'ari set debug' was moved from stasis/cli.{c,h}
to ari/cli.{c,h}, and stasis/cli.{c,h} were deleted.
* In order to print the body of incoming requests even if a request
failed, the consumption of the body was moved from the ari stubs
to ast_ari_callback in res_ari.c and the moustache templates were
then regenerated. The body is now passed to ast_ari_invoke and then
on to the handlers. This results in code savings since that template
was inserted multiple times into all the stubs.
An additional change was made to the ao2_str_container implementation
to add partial key searching and a sort function. The existing cli
code assumed it was already there when it wasn't so the tab completion
was never working.
Change-Id: Ief936f747ce47f1fb14035fbe61152cf766406bf
|
|
The mechanism used for detecting the maximum log level compiled into the
linked pjproject did not work. The API call simply stores the requested
level into an integer and does no range checking. Asterisk was assuming
that there was range checking and limited the new value to the allowable
range. To get the actual maximum log level compiled into the linked
pjproject we need to get and save off the initial set log level from
pjproject. This is the maximum log level supported.
* Get and save off the initial log level setting before altering it to the
desired level on startup. This has to be done by a macro rather than
calling a core function to avoid incorrectly linking pjproject.
* Split the initial log level warning messages to warn if the linked
pjproject cannot support the requested startup level and if it is too low
to get the pjproject buildopts for "pjproject show buildopts".
* Adjust the CLI "pjproject set log level" to check the saved max log
level and to generate normal output messages instead of a warning message.
ASTERISK-26743 #close
Change-Id: I40aa76653e2a1dece66c3f8734594b4f0471cfb4
|
|
It was possible for a frame to be re-inserted into a jitter buffer after it
had been removed from it. A case when this happened was if a frame was read
out of the jitterbuffer, passed to the translation core, and then multiple
frames were returned from said translation core. Upon multiple frames being
returned the first is passed on, but sebsequently "chained" frames are put
back into the read queue. Thus it was possible for a frame to go back into
the jitter buffer where this would cause problems.
This patch adds a flag to frames that are inserted into the channel's read
queue after translation. The abstract jitter buffer code then checks for this
flag and ignores any frames marked as such.
Change-Id: I276c44edc9dcff61e606242f71274265c7779587
|
|
The task processor queue reached X scheduled tasks message was originally
intended to get logged only once per task processor to prevent spamming
the log. This is no longer necessary since high and low water thresholds
can better control when the message is logged.
It is beneficial to generate the warning each time a task processor
reaches the high water level because PJSIP stops processing new requests
while any high water alert is active. Without this change you would have
to enable at least debug level 3 logging to know about a repeated alert
trigger.
* Made generate the warning message whenever a task is pushed into the
task processor that triggers the high water alert.
* Appended 'again' to the warning for a repeated high water alert trigger.
Change-Id: Iabf75a004f7edaf1e5e8c323099418e667cac999
|
|
* Made not generate strings unless they will actually be used.
ASTERISK-26672
Change-Id: I155fbe7fdff5ce47dfe5326f3baf5446849702c3
|
|
ASTERISK-25083
Change-Id: Id54baa57a8dbca84e29f28bcd2ffc0a5ac12d8b2
|
