A regression was introduced which removed automatic fallback behavior from
the PBX. This behavior was used by call parking (or at least documented as
how the feature works) in order to select an extension when the flat channel
extension wasn't available from the comebackcontext. Parking now handles
the fallbacks internally in order to keep behavior matching with how it is
documented.
(closes issue ASTERISK-20716)
Reported by: Chris Gentle
Review: https://reviewboard.asterisk.org/r/2296/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@380348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch came about due to a problem observed where wav files had an
empty header. The header is supposed to be updated in wav_close(). It
turns out that this was broken when the cache_record_files option from
asterisk.conf was enabled. The cleanup code was moving the file to its
final destination *before* running the close() method of the file
destructor, so the header didn't get updated.
Another problem here is that the move was being done before actually
closing the FILE *.
Finally, the last bug fixed here is that I noticed that wav_close()
checks for stream->filename to be non-NULL. In the previous cleanup
order, it's checking a pointer to freed memory. This doesn't actually
cause anything to break, but it's treading on dangerous waters. Now the
free() of stream->filename is happening after the format module's
close() method gets called, so it's safer.
Review: https://reviewboard.asterisk.org/r/2286/
........
Merged revisions 380210 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@380211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When r376428 was commited to re-order start up sequences to be more tolerant of
forking with thread primitives, a few items were changed that caused changes
in behavior on some distros. This includes:
* Not displaying the splash screen on a remote console.
* Displaying an error message on stderr when a remote console cannot connect
to a running instance of Asterisk.
In the first case, the splash screen was re-added (thanks to Michael L. Young).
In the second case, the various init.d scripts were modified to pipe stderr
to /dev/null, as the error message is useful - if you execute a remote
console or a remote console command execution and it fail, it should tell
you. Note that the error message was always present, it just failed to be
printed prior to r376428.
Much thanks to the folks who quickly reported this problem, provided solutions,
and promptly tested the various init.d scripts on a variety of distros.
(closes issue ASTERISK-20945)
Reported by: Warren Selby
Tested by: Michael L. Young, Jamuel Starkey, kaldemar, Danny Nicholas, mjordan
patches:
asterisk-20945-remote-intro-msg.diff uploaded by elguero (license 5026)
ASTERISK-20945-1.8-mjordan.diff uploaded by mjordan (license 6283)
........
Merged revisions 379760 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379777 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@379790 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk forks itself into the background via a call to daemon, it must
re-set the pid value of the new process. Otherwise, astcanary gets the pid
value of the process before the fork, which prevents it from running. Asterisk
eventually starts lowering its priority, as it can no longer communicate
with the proverbial canary in the coal mine.
This patch ensures that the correct process identifier is used by astcanary.
Note that this is getting committed to 10 as a regression fix.
(closes issue ASTERISK-20947)
Reported by: Jakob Hirsch
Tested by: mjordan
patches:
asterisk-10.12.0.astcanary_ppid.diff uploaded by Jakob Hirsch (license 6113)
........
Merged revisions 379509 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379510 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@379513 65c4cc65-6c06-0410-ace0-fbb531ad65f3
XML encoding in chan_sip is accomplished by naively building the XML
directly from strings. While this usually works, it fails to take into
account escaping the reserved characters in XML.
This patch adds an 'ast_xml_escape' function, which works similarly to
'ast_uri_encode'. This is used to properly escape the local_display
attribute in XML formatted NOTIFY messages.
Several things to note:
* The Right Thing(TM) to do would probably be to replace the
ast_build_string stuff with building an ast_xml_doc. That's a much
bigger change, and out of scope for the original ticket, so I
refrained myself.
* It is with great sadness that I wrote my own ast_xml_escape
function. There's one in libxml2, but it's knee-deep in
libxml2-ness, and not easily used to one-off escape a
string.
* I only escaped the string we know is causing problems
(local_display). At least some of the other strings are
URI-encoded, which should be XML safe. Rather than figuring out
what's safe and escaping what's not, it would be much cleaner to
simply build an ast_xml_doc for the messages and let the XML
library do the XML escaping. Like I said, that's out of scope.
(closes issue ABE-2902)
Reported by: Guenther Kelleter
Tested by: Guenther Kelleter
Review: http://reviewboard.digium.internal/r/365/
........
Merged revision 378919 from https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
........
Merged revisions 378933 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378934 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This test event was missing from channel.c causing the dial_LS_options
test to fail intermittently because of a race condition where most code
paths emitted the test event but this one did not. The dial_LS_options
test should stop bouncing now.
........
Merged revisions 378455 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378459 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When reading configuration data from an Asterisk .conf file or when pulling
data from an Asterisk RealTime backend, Asterisk was copying the data on the
stack for manipulation. Unfortunately, it is possible to read configuration
data or realtime data from some data source that provides a large blob of
characters. This could potentially cause a crash via a stack overflow.
This patch prevents large sets of data from being read from an ARA backend or
from an Asterisk conf file.
(issue ASTERISK-20658)
Reported by: wdoekes
Tested by: wdoekes, mmichelson
patches:
* issueA20658_dont_process_overlong_config_lines.patch uploaded by wdoekes (license 5674)
* issueA20658_func_realtime_limit.patch uploaded by wdoekes (license 5674)
........
Merged revisions 378375 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378376 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AMI redirect action can fail to redirect two channels that are bridged
together. There is a race between the AMI thread redirecting the two
channels and the bridge thread noticing that a channel is hungup from the
redirects.
* Made the bridge wait for both channels to be redirected before exiting.
* Made the AMI redirect check that all required headers are present before
proceeding with the redirection.
* Made the AMI redirect require that any supplied ExtraChannel exist
before proceeding. Previously the code fell back to a single channel
redirect operation.
(closes issue ASTERISK-18975)
Reported by: Ben Klang
(closes issue ASTERISK-19948)
Reported by: Brent Dalgleish
Patches:
jira_asterisk_19948_v11.patch (license #5621) patch uploaded by rmudgett
Tested by: rmudgett, Thomas Sevestre, Deepak Lohani, Kayode
Review: https://reviewboard.asterisk.org/r/2243/
........
Merged revisions 378356 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378358 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk maintains an internal cache for devices in the event subsystem. The
device state cache holds the state of each device known to Asterisk, such that
consumers of device state information can query for the last known state for
a particular device, even if it is not part of an active call. The concept of
a device in Asterisk can include entities that do not have a physical
representation. One way that this occurred was when anonymous calls are allowed
in Asterisk. A device was automatically created and stored in the cache for
each anonymous call that occurred; this was possible in the SIP and IAX2
channel drivers and through channel drivers that utilized the
res_jabber/res_xmpp resource modules (Gtalk, Jingle, and Motif). These devices
are never removed from the system, allowing anonymous calls to potentially
exhaust a system's resources.
This patch changes the event cache subsystem and device state management to
no longer cache devices that are not associated with a physical entity.
(issue ASTERISK-20175)
Reported by: Russell Bryant, Leif Madsen, Joshua Colp
Tested by: kmoore
patches:
event-cachability-3.diff uploaded by jcolp (license 5000)
........
Merged revisions 378303 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378320 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378321 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk had several places where messages received over various network
transports may be copied in a single stack allocation. In the case of TCP,
since multiple packets in a stream may be concatenated together, this can
lead to large allocations that overflow the stack.
This patch modifies those portions of Asterisk using TCP to either
favor heap allocations or use an upper bound to ensure that the stack will not
overflow:
* For SIP, the allocation now has an upper limit
* For HTTP, the allocation is now a heap allocation instead of a stack
allocation
* For XMPP (in res_jabber), the allocation has been eliminated since it was
unnecesary.
Note that the HTTP portion of this issue was independently found by Brandon
Edwards of Exodus Intelligence.
(issue ASTERISK-20658)
Reported by: wdoekes, Brandon Edwards
Tested by: mmichelson, wdoekes
patches:
ASTERISK-20658_res_jabber.c.patch uploaded by mmichelson (license 5049)
issueA20658_http_postvars_use_malloc2.patch uploaded by wdoekes (license 5674)
issueA20658_limit_sip_packet_size3.patch uploaded by wdoekes (license 5674)
........
Merged revisions 378269 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378286 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378287 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was causing issues when using DESTDIR, since the path to which the link
pointed is not likely to exist (and not useful to exist) on the target system.
(issue ASTNOW-284)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378073 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made ast_unregister_indication_country() unlink the found tone zone
before selecting a new default_tone_zone to make it impossible to select
the tone zone being unregistered again.
* Ringcadence is no longer parsed twice in store_config_tone_zone().
* Cleanup CLI commands and destroy default_tone_zone on exit.
(issue ASTERISK-20649)
Reported by: Corey Farrell
Patches:
indications-cleanup-all.patch (license #5909) patch uploaded by Corey Farrell
Modified
........
Merged revisions 377740 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 377741 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@377742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the CLI command 'manager show event' was run incorrectly and its usage
instructions returned, a reference to the event container was leaked. This
would prevent the container from being reclaimed when Asterisk exits. We now
properly decrement the count on the ao2 object using the nifty RAII_VAR macro.
Thanks to Russell for helping me stumble on this, and Terry for writing that
ridiculously helpful macro.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@377319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Adds the following CLI commands to control MALLOC_DEBUG reporting of
unreleased malloc memory when Asterisk is shut down.
memory atexit list on
memory atexit list off
memory atexit summary byline
memory atexit summary byfunc
memory atexit summary byfile
memory atexit summary off
* Made check all remaining allocated region blocks atexit for fence
violations.
* Increased the allocated region hash table size by about three times. It
still isn't large enough considering the number of malloced blocks
Asterisk uses.
* Made CLI "memory show allocations anomalies" use
regions_check_all_fences().
Review: https://reviewboard.asterisk.org/r/2196/
........
Merged revisions 376788 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 376789 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376790 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed CLI "memory show allocations" misspelling of anomalies option.
The command will still accept the original misspelling.
* Miscellaneous tweaks to CLI "memory show allocations" command output
format.
* Made CLI "memory show summary" summarize by line number instead of by
function if a filename is given.
* Made CLI "memory show summary" sort its output by filename or
function-name/line-number depending upon request.
* Miscellaneous tweaks to CLI "memory show summary" command output format.
........
Merged revisions 376758 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 376759 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, challenge would yield a multiple logins error if used
without providing the username (which isn't really supposed to be an argument
to challenge) if allowmultiplelogin was set to no because allowmultiplelogin
finds a user with a zero length login name. This check is simply disabled for
the challenge action when the username is empty by this patch.
(closes issue ASTERISK-20677)
Reported by: Vladimir
Patches:
challenge_action_nomultiplelogin.diff uploaded by Jonathan Rose (license 6182)
........
Merged revisions 376725 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 376726 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376727 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The '-' char is supposed to be ignored by the dialplan extension matching.
Unfortunately, it's treatment is not handled consistently throughout the
extension matching code.
* Made the old exten matching code consistently ignore '-' chars.
* Made the old exten matching code consistently handle case in the
matching.
* Made ignore empty character sets.
* Fixed ast_extension_cmp() to return -1, 0, or 1 as documented. The only
user of it in pbx_lua.c was testing for -1. It was originally returning
the strcmp() value for less than which is not usually going to be -1.
* Fix character set sorting if the sets have the same number of characters
and start with the same character. Character set [0-9] now sorts before
[02-9a] as originally intended.
* Updated some extension label and priority already in use warnings to
also indicate if the extension is aliased.
(closes issue ASTERISK-19205)
Reported by: Philippe Lindheimer, Birger "WIMPy" Harzenetter
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/2201/
........
Merged revisions 376688 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 376689 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376690 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Similar to the patch that moved the fork earlier in the startup sequence to
prevent mutex errors in the recursive mutex surrounding the read/write thread
registration lock, this patch re-initializes the logmsgs mutex. Part of the
start up sequence before forking the process into the background includes
reading asterisk.conf; this has to occur prior to the call to daemon in order
to read startup parameters. When reading in a conf file, log statements can
be generated. Since this can't be avoided, the mutex instead is
re-initialized to ensure a reset of any thread tracking information.
This patch also includes some additional debugging to catch errors when
locking or unlocking the recursive mutex that surrounds locks when the
DEBUG_THREADS build option is enabled. DO_CRASH or THREAD_CRASH will
cause an abort() if a mutex error is detected.
(issue ASTERISK-19463)
Reported by: mjordan
Tesetd by: mjordan
........
Merged revisions 376586 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 376587 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376588 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Although it is very rare and timing dependent, the potential exists for the
call to 'daemon' to cause what appears to be a deadlock in Asterisk during
startup. This can occur when a recursive mutex is obtained prior to the
daemon call executing. Since daemon uses fork to send the process into the
background, any threading primitives are unsafe to re-use after the call.
Implementations of pthread recursive mutexes are highly likely to store the
thread identifier of the thread that previously obtained the mutex. If
the mutex was locked prior to the fork, a subsequent unlock operation will
potentially fail as the thread identifier is no longer valid. Since the
mutex is still locked, all subsequent attempts to grab the mutex by other
threads will block.
This behavior exhibited itself most often when DEBUG_THREADS was enabled, as
this compile time option surrounds the mutexes in Asterisk with another
recursive mutex that protects the storage of thread related information. This
made it much more likely that a recursive mutex would be obtained prior to
daemon and unlocked after the call.
This patch does the following:
a) It backports a patch from Asterisk 11 that prevents the spawning of the
localtime monitoring thread. This thread is now spawned after Asterisk has
fully booted.
b) It re-orders the startup sequence to call daemon earlier during Asterisk
startup. This limits the potential of threading primitives being accessed
by initialization calls before daemon is called.
c) It removes calls to ast_verbose/ast_log/etc. prior to daemon being called.
Developers should send error messages directly to stderr prior to daemon,
as calls to ast_log may access recursive mutexes that store thread related
information.
d) It reorganizes when thread local storage is created for storing lock
information during the creation of threads. Prior to this patch, the
read/write lock protecting the list of threads in ast_register_thread would
utilize the lock in the thread local storage prior to it being initialized;
this patch prevents that.
On a very related note, this patch will *greatly* improve the stability of the
Asterisk Test Suite.
Review: https://reviewboard.asterisk.org/r/2197
(closes issue ASTERISK-19463)
Reported by: mjordan
Tested by: mjordan
........
Merged revisions 376428 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 376431 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376441 65c4cc65-6c06-0410-ace0-fbb531ad65f3
generator.
This patch introduces an internal helper function to safely check whether the
current generator is the one that is expected before deactivating it. The
current externally accessible ast_channel_stop_generator() function has been
modified to be implemented in terms of the new function.
(closes issue ASTERISK-19918)
Reported by: Eduardo Abad
........
Merged revisions 376199 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 376208 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The code which handles the ShowDialPlan action wrongly assumed that a non-NULL return value
from the function which retrieves headers from an action indicates that the header has a
value. This is incorrect and the contents must be checked to see if they are blank.
(closes issue ASTERISK-20628)
Reported by: jkroon
Patches:
asterisk-showdialplan-incorrect-error.patch uploaded by jkroon
........
Merged revisions 376166 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 376167 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@376168 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Richard Mudgett
Jonathan Rose
Russell Bryant
Matthew Jordan
Walter Doekes
David M. Lee
Mark Michelson
Kinsey Moore
Jason Parker
Tilghman Lesher
Brent Eagles
Joshua Colp
Michael L. Young