| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
In versiong 5.5, OpenBSD went to 64-bit time values. This requires a cast to
(long) when printing members of certain time structs.
Review: https://reviewboard.asterisk.org/r/4507
ASTERISK-24879 #close
Reported by: snuffy
Tested by: snuffy
patches:
openbsd-time64.diff uploaded by snuffy (License 5024)
........
Merged revisions 433268 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433269 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
|
|
When logger.conf is missing or invalid enable console logging and display
an error message.
ASTERISK-24817 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4497/
........
Merged revisions 433122 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433126 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Using DEBUG_CHAOS several instances of a null
pointer crash, and one uninitialized variable
were uncovered and fixed. Also added details
on why Asterisk failed to initialize.
Review: https://reviewboard.asterisk.org/r/4468/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433064 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
|
|
Snapshots are immutable and are never changed. Allocating them
with a lock is wasteful.
Review: https://reviewboard.asterisk.org/r/4469/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432742 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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432556 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
|
|
Fixed a couple of frame leaks that were found during testing.
ASTERISK-24828 #close
Reported by: John Hardin
Review: https://reviewboard.asterisk.org/r/4445/
........
Merged revisions 432362 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432363 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Prior to this patch, SDP offers negotiating SDES-SRTP crypto attributes would
be rejected if those crypto attributes contained either a key lifetime or a
MKI parameter. While from a theoretical point of view this was defensible -
Asterisk does not support key lifetimes or multiple crypto keys - from a
practical point of view, this is quite a problem. A large number of endpoints
offer lifetimes/MKI, which Asterisk can tolerate so long as it doesn't actually
have to support anything more than a single key or refresh the key.
In reality, this is (so far as we've seen) always the case.
This patch is a forward port of Olle's work in the lingon-srtp-key-lifetime-1.8
branch. To quote Olle from ASTERISK-17721, it handles lifetime/MKI parameters
in the following fashion:
> The Lingon branch now handle lifetime and MKI parameters.
>
> We only accept lifetimes up to max for the crypto and higher than 10 hours
> for packetization of 20 ms (50 pps).
>
> We only handle MKI with index 1.
>
> We do not really bother with counting packets and reinviting at end of
> lifetime, so the min of 10 hours kind of takes care of most calls. If there
> are longer ones, we rely on the other side for re-invites.
>
> It's still not perfect, but I personally think this is an improvement. A
> configuration option for minimum lifetime accepted could be added.
When the patch was ported forward, I decided against adding a configuration
option as Olle's handling was more than sufficient for every case I've seen
come through the issue tracker or through interoperability testing. We can
revisit that decision if it proves to be false.
A few small other tweaks were made to the surrounding code to reduce
indentation and provide better type safety for the 'tag' parameter.
Review: https://reviewboard.asterisk.org/r/4419/
Review: https://reviewboard.asterisk.org/r/4418/
ASTERISK-17721 #close
Reported by: Terry Wilson
ASTERISK-17899 #close
Reported by: Dwayne Hubbard
patches:
lingon-srtp-key-lifetime-1.8.diff uploaded by oej (License 5267)
ASTERISK-20233
Reported by: tootai
ASTERISK-22748
Reported by: Alejandro Mejia
........
Merged revisions 432239 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432258 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch addresses the following problems:
* ari/resource_channels: In ARI, we currently create a format capability
structure of SLIN and apply it to the new channel being created. This was
originally done when the PBX core was used to create the channel, as there
was a condition where a newly created channel could be created without any
formats. Unfortunately, now that the Dial API is being used, this has two
drawbacks:
(a) SLIN, while it will ensure audio will flows, can cause a lot of
needless transcodings to occur, particularly when a Local channel is
created to the dialplan. When no format capabilities are available, the
Dial API handles this better by handing all audio formats to the requsted
channels. As such, we defer to that API to provide the format
capabilities.
(b) If a channel (requester) is causing this channel to be created, we
currently don't use its format capabilities as we are passing in our own.
However, the Dial API will use the requester channel's formats if none
are passed into it, and the requester channel exists and has format
capabilities. This is the "best" scenario, as it is the most likely to
create a media path that minimizes transcoding.
Fixing this simply entails removing the providing of the format capabilities
structure to the Dial API.
* chan_pjsip: Rather than blindly picking the first format in the format
capability structure - which actually *can* be a video or text format - we
select an audio format, and only pick the first format if that fails. That
minimizes the weird scenario where we attempt to transcode between video/audio.
* res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure.
Since ast_request already limits us down to one format capability once the
format capabilities are passed along, there's no reason to squelch it here.
* channel: Fixed a comment. The reason we have to minimize our requested
format capabilities down to a single format is due to Asterisk's inability
to convey the format to be used back "up" a channel chain. Consider the
following:
PJSIP/A => L;1 <=> L;2 => PJSIP/B
g,u,a g,u,a g,u,a u
That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials
PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local
channel has inherited those format capabilities down the line; PJSIP/B
supports only ulaw. According to these format capabilities, ulaw is
acceptable and should be selected across all the channels, and no
transcoding should occur. However, there is no way to convey this: when L;2
and PJSIP/B are put into a bridge, we will select ulaw, but that is not
conveyed to PJSIP/A and L;1. Thus, we end up with:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
g g X u u
Which causes g722 to be written to PJSIP/B.
Even if we can convey the 'ulaw' choice back up the chain (which through
some severe hacking in Local channels was accomplished), such that the chain
looks like:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
u u u u
We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back
with only 'ulaw'. This results in all the channel structures being set up
correctly, but PJSIP/A *still* sending g722 and causing the chain to fall
apart.
There's a lot of difficulty just in setting this up, as there are numerous
race conditions in the act of bridging, and no clean mechanism to pass the
selected format backwards down an established channel chain. As such, the
best that can be done at this point in time is clarifying the comment.
Review: https://reviewboard.asterisk.org/r/4434/
ASTERISK-24812 #close
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432195 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
ASTERISK-24724 #close
Reported by: Ashley Sanders
........
Merged revisions 432078 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* Change __ast_module_shutdown_ref to be NULL safe (11+).
* Allow modules that call ast_bucket_scheme_register or ast_codec_register
to be unloaded during graceful shutdown only (13+ only).
ASTERISK-24796 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4428/
........
Merged revisions 432058 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432059 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
association.
Processing an AOC-E event that does not or no longer has a channel
association causes a crash.
The problem with posting AOC events to the channel topic is that AOC-E
events don't always have a channel association and posting the event to
the all channels topic is just wrong. AOC-E events do however have their
own charging association method to refer to the agreement with the
charging entity.
* Changed the AOC events to post to the AMI manager topic instead of the
channel topics. If a channel is associated with the event then channel
snapshot information is supplied with the AMI event.
* Eliminated RAII_VAR() usage in aoc_to_ami() and ast_aoc_manager_event().
This patch supercedes the patch on Review: https://reviewboard.asterisk.org/r/4427/
ASTERISK-22670 #close
Reported by: klaus3000
ASTERISK-24689 #close
Reported by: Marcel Manz
ASTERISK-24740 #close
Reported by: Panos Gkikakis
Review: https://reviewboard.asterisk.org/r/4430/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431974 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Some distributions are going to disable SSLv3 at compile time. This option can
be checked using the directive OPENSSL_NO_SSL3_METHOD. This patch updates the
TCP/TLS handling in Asterisk to look for that directive before attempting to
use the SSLv3 specific methods.
ASTERISK-24799 #close
Reported by: Alexander Traud
patches:
no-ssl3-method.patch uploaded by Alexander Traud (License 6520)
........
Merged revisions 431936 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431937 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* Added ast_sched_clean_by_callback for cleanup of scheduled events
that have not yet fired.
* Run all pending peercnt_remove_cb and replace_callno events in chan_iax2.
Cleanup of replace_callno events is only run 11, since it no longer
releases any references or allocations in 13+.
ASTERISK-24451 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4425/
........
Merged revisions 431916 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
and it isn't found.
ASTERISK-24612 #close
Reported by: Joshua Colp
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
There are three CLI commands to stop and restart Asterisk each.
1) core stop/restart now - Hangup all calls and stop or restart Asterisk.
New channels are prevented while the shutdown request is pending.
2) core stop/restart gracefully - Stop or restart Asterisk when there are
no calls remaining in the system. New channels are prevented while the
shutdown request is pending.
3) core stop/restart when convenient - Stop or restart Asterisk when there
are no calls in the system. New calls are not prevented while the
shutdown request is pending.
ARI has made stopping/restarting Asterisk more problematic. While a
shutdown request is pending it is desirable to continue to process ARI
HTTP requests for current calls. To handle the current calls while a
shutdown request is pending, a new committed to shutdown phase is needed
so ARI applications can deal with the calls until the system is fully
committed to shutdown.
* Added a new shutdown committed phase so ARI applications can deal with
calls until the final committed to shutdown phase is reached.
* Made refuse new HTTP requests when the system has reached the final
system shutdown phase. Starting anything while the system is actively
releasing resources and unloading modules is not a good thing.
* Split the bridging framework shutdown to not cleanup the global bridging
containers when shutting down in a hurry. This is similar to how other
modules prevent crashes on rapid system shutdown.
* Moved ast_begin_shutdown(), ast_cancel_shutdown(), and
ast_shutting_down(). You should not have to include channel.h just to
access these system functions.
ASTERISK-24752 #close
Reported by: Matthew Jordan
Review: https://reviewboard.asterisk.org/r/4399/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Add ast_module_shutdown_ref for use by modules that can
only be unloaded during graceful shutdown.
When REF_DEBUG is enabled:
* Add an empty ao2 object to struct ast_module.
* Allocate ao2 object when the module is loaded.
* Perform an ao2_ref in each place where mod->usecount is manipulated.
* ao2_cleanup on module unload.
ASTERISK-24479 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4141/
........
Merged revisions 431662 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431663 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In this collection of small patches to prevent
Valgrind errors are: fixes for reference leaks
in config hooks, evaluating a parameter beyond
bounds, and accessing a structure after a lock
where it could have been already free'd.
Review: https://reviewboard.asterisk.org/r/4407/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431583 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The act of defining wizards for an object type in sorcery.conf will
create a minimal object type. This can cause a problem when a module
has multiple sorcery instances (which all get the wizards from sorcery.conf
applied) but the sorcery instances do not all contain full information
about the object types. Upon loading errors will occur stating that
the objects can not be created. This is confusing and is actually
perfectly fine.
This change makes it so that only object types which have been fully
defined will be loaded.
ASTERISK-24748 #close
Reported by: Joshua Colp
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Added a new config property [servername] to the http.conf file; updated the http server to use the new property when sending responses, for showing http status through the CLI and when reporting status through the 'httpstatus' webpage.
ASTERISK-24316 #close
Reported By: Andrew Nagy
Review: https://reviewboard.asterisk.org/r/4374/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
These memory leaks were found and fixed by John Hardin. I'm just
committing them for him.
ASTERISK-24736 #close
Reported by Mark Michelson
Review: https://reviewboard.asterisk.org/r/4389
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431468 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When swapping a Local channel in place of one already
in a bridge (to complete a bridge attended transfer),
the channel that was swapped out can actually be hung
up before the stasis bridge push callback executes on
the independant transfer thread. This results in the
stasis app loop dropping out and removing the control
that has the the app name which the local replacement
channel needs so it can re-enter stasis.
To avoid this race condition a new push_peek callback
has been added, and called from the ast_bridge_impart
thread before it launches the independant thread that
will complete the transfer. Now the stasis push_peek
callback can copy the stasis app name before the swap
channel can hang up.
ASTERISK-24649
Review: https://reviewboard.asterisk.org/r/4382/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431450 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Performing a CLI "module reload" command when there are new pjsip.conf
registration objects defined frequently failed to load them correctly.
What happens is a race condition between res_pjsip pushing its reload into
an asynchronous task processor task and the thread that does the rest of
the reloads when it gets to reloading the res_pjsip_outbound_registration
module. A similar race condition happens between a reload and the CLI/AMI
show registrations commands. The reload updates the current_states
container and the CLI/AMI commands call get_registrations() which builds a
new current_states container.
* Made res_pjsip.c reload_module() use ast_sip_push_task_synchronous()
instead of ast_sip_push_task() to eliminate two threads processing config
reloads at the same time.
* Made get_registrations() not replace the global current_states container
so the CLI/AMI show registrations command cannot interfere with reloading.
You could never add/remove objects in the container without the
possibility of the container being replaced out from under you by
get_registrations().
* Added a registration loaded sorcery instance observer to purge any dead
registration objects since get_registrations() cannot do this job anymore.
The struct ast_sorcery_instance_observer callbacks must be used because
the callback happens inline with the load process. The struct
ast_sorcery_observer callbacks are pushed to a different thread.
* Added some global current_states NULL pointer checks in case the
container disappears because of unload_module().
* Made sorcery's struct ast_sorcery_instance_observer.object_type_loaded
callbacks guaranteed to be called before any struct
ast_sorcery_observer.loaded callbacks will be called.
* Moved the check for non-reloadable objects to before the sorcery
instance loading callbacks happen to short circuit unnecessary work.
Previously with non-reloadable objects, the sorcery instance
loading/loaded callbacks would always happen, the individual wizard
loading/loaded would be prevented, and the non-reloadable type logging
message would be logged for each associated wizard.
ASTERISK-24729 #close
Review: https://reviewboard.asterisk.org/r/4381/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431243 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
While running through some scenarios using chan_sip and tcp a problem would
occur that resulted in a flood of bad file descriptor messages on the cli:
tcptls.c:712 ast_tcptls_server_root: Accept failed: Bad file descriptor
The message is received because the underlying socket has been closed, so is
valid. This is probably happening because unloading of chan_sip is not atomic.
That however is outside the scope of this patch. This patch simply stops the
logging of multiple occurrences of that message.
ASTERISK-24728 #close
Reported by: Thomas Thompson
Review: https://reviewboard.asterisk.org/r/4380/
........
Merged revisions 431218 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431219 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Due to the original patch causing memory corruptions it was removed until the
problem could be resolved. This patch is the original patch plus some added
locking around stasis router subcription that was needed to avoid the memory
corruption.
Description of the original problem and patch (still applicable):
The res_pjsip module was previously unloadable. With this patch it can now
be unloaded.
This patch is based off the original patch on the issue (listed below) by Corey
Farrell with a few modifications. Namely, removed a few changes not required to
make the module unloadable and also fixed a bug that would cause asterisk to
crash on unloading.
This patch is the first step (should hopefully be followed by another/others at
some point) in allowing res_pjsip and the modules that depend on it to be
unloadable. At this time, res_pjsip and some of the modules that depend on
res_pjsip cannot be unloaded without causing problems of some sort.
The goal of this patch is to get res_pjsip and only res_pjsip to be able to
unload successfully and/or shutdown without incident (crashes, leaks, etc...).
Other dependent modules may still cause problems on unload.
Basically made sure, with the patch applied, that res_pjsip (with no other
dependent modules loaded) could be succesfully unloaded and Asterisk could
shutdown without any leaks or crashes that pertained directly to res_pjsip.
ASTERISK-24485 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4363/
patches:
pjsip_unload-broken-r1.patch submitted by Corey Farrell (license 5909)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431179 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
direct media.
This change fixes two issues:
1. During a swap operation bridging added the new channel before having the swap channel
leave. This was not handled in bridge_native_rtp and could result in a channel not getting
reinvited back to Asterisk. After this change the swap channel will leave first and the
new channel will then join.
2. If a re-invite was received after a session had been established any upstream elements
(such as bridge_native_rtp) were not notified that they may want to re-evaluate things.
After this change an UPDATE_RTP_PEER control frame is queued when this situation occurs
and upstream can react.
AST-1524 #close
Review: https://reviewboard.asterisk.org/r/4378/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431157 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Prior to this patch, ModuleLoad would respond with an error indicating that
the requested module wasn't found in spite of finding and reloading the
module.
Review: https://reviewboard.asterisk.org/r/4373/
ASTERISK-24721 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431153 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch addresses compilation errors on OS X. It's been a while, so
there's quite a few things.
* Fixed __attribute__ decls in route.h to be portable.
* Fixed htonll and ntohll to work when they are defined as macros.
* Replaced sem_t usage with our ast_sem wrapper.
* Added ast_sem_timedwait to our ast_sem wrapper.
* Fixed some GCC 4.9 warnings using sig*set() functions.
* Fixed some format strings for portability.
* Fixed compilation issues with res_timing_kqueue (although tests still fail
on OS X).
* Fixed menuconfig /sbin/launchd detection, which disables res_timing_kqueue
on OS X).
ASTERISK-24539 #close
Reported by: George Joseph
ASTERISK-24544 #close
Reported by: George Joseph
Review: https://reviewboard.asterisk.org/r/4327/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431092 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When a crash was fixed due to usage of the REALTIME function in r423003, a
regression was introduced into ast_update2_realtime where the update fields
passed to the function would be skipped and the lookup field processed twice.
The use of this function is a bit interesting: A variable argument list is
used with two sentinel values - the first marks the end of the lookup
fields/values; the second marks the end of the update fields/values.
Unfortunately, ast_update2_realtime parses over the lookup fields twice, as
opposed to parsing over the update fields. This causes the lookups to succeed,
but the updates itself to have no effect.
Note that the most common instance of this problem occurred in app_voicemail
during the updating of a mailbox password.
Thanks to the issue reporter, Paddy Grice, for pointing out the problem.
Review: https://reviewboard.asterisk.org/r/4356/
ASTERISK-24231
ASTERISK-24626 #close
Reported by: Paddy Grice
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431072 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 430996 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430998 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When code imparts a channel into a bridge to swap with another channel, a
ref needs to be held on the swap channel to ensure that it cannot
dissapear before finding it in the bridge.
* The ast_bridge_join() swap channel parameter now always steals a ref for
the swap channel. This is the only change to the bridge framework's
public API semantics.
* bridge_channel_internal_join() now requires the bridge_channel->swap
channel to pass in a ref.
ASTERISK-24649
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4354/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430975 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When the RTCP reports are created, the NTP timestamps are stored as strings,
as JSON does not have an integer type long enough to store the value. However,
on 32-bit systems, a signed long may overflow for some portion of the
timestamp.
This patch corrects the overflow by formatting the timestamps as unsigned
longs.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430840 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When a hint gets created, any subsequent device or presence
state changes result in extension status events getting sent
out to interested parties. However, at the time of hint creation,
no such event gets sent out, so watchers of extension state are
potentially left in the dark until the first state change after
hint creation.
Patch contributed by John Hardin (License #6512)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430776 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Due to the original patch causing memory corruptions the patch is
being removed until the problem can be resolved.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430734 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The res_pjsip module was previously unloadable. With this patch it can now
be unloaded.
This patch is based off the original patch on the issue (listed below) by Corey
Farrell with a few modifications. Namely, removed a few changes not required to
make the module unloadable and also fixed a bug that would cause asterisk to
crash on unloading.
This patch is the first step (should hopefully be followed by another/others at
some point) in allowing res_pjsip and the modules that depend on it to be
unloadable. At this time, res_pjsip and some of the modules that depend on
res_pjsip cannot be unloaded without causing problems of some sort.
The goal of this patch is to get res_pjsip and only res_pjsip to be able to
unload successfully and/or shutdown without incident (crashes, leaks, etc...).
Other dependent modules may still cause problems on unload.
Basically made sure, with the patch applied, that res_pjsip (with no other
dependent modules loaded) could be succesfully unloaded and Asterisk could
shutdown without any leaks or crashes that pertained directly to res_pjsip.
ASTERISK-24485 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4311/
patches:
pjsip_unload-broken-r1.patch submitted by Corey Farrell (license 5909)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430628 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* Reverted the change to astman_send_listack() to not use the listflag
parameter and always set the value to "Start" so the start capitalization
is consistent. Unfortunately changing the case of a returned value is not
a backward compatible change so for now FAXSessions is going to have to
remain inconsistent with all of the other AMI list actions.
* Reverted the minor protocol error fix in action_getconfig() when no
requested categories are found. Each line needs to be formatted as
"Header: text".
Caught by the testsuite.
ASTERISK-24049
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The security event log uses a dynamic log level (SECURITY) that is registered
with the Asterisk logging core. Unfortunately, the syslog would ignore log
statements that had a dynamic log level associated with them. Because the
syslog cannot handle ad hoc dynamic log levels, this patch treats any dynamic
log entries sent to the syslog as logs with a level of NOTICE.
ASTERISK-20744 #close
Reported by: Michael Keuter
Tested by: Michael L. Young, Jacek Konieczny
patches:
asterisk-20744-syslog-dynamic-logging_trunk.diff uploaded by Michael L. Young (license 5026)
........
Merged revisions 430506 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430507 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When app_bridge grabs a channel and puts it into
a bridge, the channel should then continue where
it left off in the dialplan after the bridge has
ended. Although it stores the current dialplan
location as an after bridge goto on the channel,
it was executing the same priority again instead
of going to the next priority. By swapping the
"specific" version of bridge_set_after_goto with
bridge_set_after_go_on, the next priority in the
dialplan is executed instead.
ASTERISK-24637 #close
Review: https://reviewboard.asterisk.org/r/4322/
Reported by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430467 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
