We have some functions inside the AstData API to get the tree
in XML form, but it is not required at the moment to compile
asterisk and we can disable that part of the API if we don't have
libxml2 support.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@260521 f38db490-d61c-443f-a65b-d21fe96a405b
This saves time, when, even though the system allows the process limit to be
that high, the practical limit is much lower. Also introduce an additional
optimization, in the form of using the CLOEXEC flag to close descriptors at
the right time.
(closes issue #17223)
Reported by: dbackeberg
Patches:
20100423__issue17223.diff.txt uploaded by tilghman (license 14)
Tested by: dbackeberg
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@260292 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r260049 | dvossel | 2010-04-29 10:31:02 -0500 (Thu, 29 Apr 2010) | 14 lines
Fixes crash in audiohook_write_list
The middle_frame in the audiohook_write_list function was
being freed if a audiohook manipulator returned a failure.
This is incorrect logic. This patch resolves this and
adds detailed descriptions of how this function should work
and why manipulator failures must be ignored.
(closes issue #17052)
Reported by: dvossel
Tested by: dvossel
(closes issue #16196)
Reported by: atis
Review: https://reviewboard.asterisk.org/r/623/
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@260050 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259858 | dvossel | 2010-04-28 16:16:03 -0500 (Wed, 28 Apr 2010) | 33 lines
resolves deadlocks in chan_local
Issue_1.
In the local_hangup() 3 locks must be held at the same time... pvt, pvt->chan,
and pvt->owner. Proper deadlock avoidance is done when the channel to hangup
is the outbound chan_local channel, but when it is not the outbound channel we
have an issue... We attempt to do deadlock avoidance only on the tech pvt, when
both the tech pvt and the pvt->owner are locked coming into that loop. By
never giving up the pvt->owner channel deadlock avoidance is not entirely possible.
This patch resolves that by doing deadlock avoidance on both the pvt->owner and the pvt
when trying to get the pvt->chan lock.
Issue_2.
ast_prod() is used in ast_activate_generator() to queue a frame on the channel
and make the channel's read function get called. This function is used in
ast_activate_generator() while the channel is locked, which mean's the channel
will have a lock both from the generator code and the frame_queue code by the
time it gets to chan_local.c's local_queue_frame code... local_queue_frame
contains some of the same crazy deadlock avoidance that local_hangup requires,
and this recursive lock prevents that deadlock avoidance from happening correctly.
This patch removes ast_prod() from the channel lock so only one lock is held during
the local_queue_frame function.
(closes issue #17185)
Reported by: schmoozecom
Patches:
issue_17185_v1.diff uploaded by dvossel (license 671)
issue_17185_v2.diff uploaded by dvossel (license 671)
Tested by: schmoozecom, GameGamer43
Review: https://reviewboard.asterisk.org/r/631/
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@259870 f38db490-d61c-443f-a65b-d21fe96a405b
autoconf2.13 couldn't handle AC_PROG_GREP, so I removed it. This is fine,
since we don't need to use anything that the configure script doesn't.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@259439 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259018 | mmichelson | 2010-04-26 16:03:08 -0500 (Mon, 26 Apr 2010) | 13 lines
Prevent Newchannel manager events for dummy channels.
No Newchannel manager event will be fired for channels that are
allocated to not match a registered technology type. Thus bogus
channels allocated solely for variable substitution or CDR
operations do not result in a Newchannel event.
(closes issue #16957)
Reported by: atis
Review: https://reviewboard.asterisk.org/r/601
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@259023 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r193391 | mnicholson | 2009-05-08 16:01:25 -0500 (Fri, 08 May 2009) | 8 lines
Set the proper disposition on originated calls.
(closes issue #14167)
Reported by: jpt
Patches:
call-file-missing-cdr2.diff uploaded by mnicholson (license 96)
Tested by: dlotina, rmartinez, mnicholson
........
r258670 | mnicholson | 2010-04-22 16:49:07 -0500 (Thu, 22 Apr 2010) | 11 lines
Fix broken CDR behavior.
This change allows a CDR record previously marked with disposition ANSWERED to be set as BUSY or NO ANSWER.
Additionally this change partially reverts r235635 and does not set the AST_CDR_FLAG_ORIGINATED flag on CDRs generated from ast_call(). To preserve proper CDR behavior, the AST_CDR_FLAG_DIALED flag is now cleared from all brige CDRs in ast_bridge_call().
(closes issue #16797)
Reported by: VarnishedOtter
Tested by: mnicholson
........
(closes issue #16222)
Reported by: telles
Tested by: mnicholson
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@258671 f38db490-d61c-443f-a65b-d21fe96a405b
This patch introduces another test in test_event.c that exercises most of the
subscription related ast_event API calls. I made some minor additions to the
existing event allocation test to increase API coverage by the test code.
Finally, I made a list in a comment of API calls not yet touched by the test
module as a to-do list for future test development.
During the development of this test code, I discovered a number of bugs in
the event API.
1) subscriptions to AST_EVENT_ALL were not handled appropriately in a couple
of different places. The API allows a subscription to all event types,
but with IE parameters, just as if it was a subscription to a specific
event type. However, the parameters were being ignored. This affected
ast_event_check_subscriber() and event distribution to subscribers.
2) Some of the logic in ast_event_check_subscriber() for checking subscriptions
against query parameters was wrong.
Review: https://reviewboard.asterisk.org/r/617/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@258632 f38db490-d61c-443f-a65b-d21fe96a405b
"Bad Things" would happen if Asterisk was compiled with DEBUG_THREADS, but a
loaded module was not (or vice versa). This also immensely simplifies the
lock code, since there are no longer 2 separate versions of them.
Review: https://reviewboard.asterisk.org/r/508/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@258557 f38db490-d61c-443f-a65b-d21fe96a405b
This module implements an abstraction for retrieving and exporting
asterisk data.
Developed by:
Brett Bryant <brettbryant@gmail.com>
Eliel C. Sardanons (LU1ALY) <eliels@gmail.com>
For the Google Summer of code 2009 Project.
Documentation can be found in doxygen format and inside the
header include/asterisk/data.h
Review: https://reviewboard.asterisk.org/r/275/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@258517 f38db490-d61c-443f-a65b-d21fe96a405b
Added a new manager command to mute/unmute MixMonitor audio on a channel.
Added a new feature to audiohooks so that you can mute either read / write
(or both) types of frames - this allows for MixMonitor to mute either side
of the conversation without affecting the conversation itself.
(closes issue #16740)
Reported by: jmls
Review: https://reviewboard.asterisk.org/r/487/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@258190 f38db490-d61c-443f-a65b-d21fe96a405b
There were many changes in revision 176627 which would avoid the error that a
missing config would have caused. Other than this, there are no other config
files (including asterisk.conf, surprisingly) that are required.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@257947 f38db490-d61c-443f-a65b-d21fe96a405b
Because res/res_features.c was removed and main/cdr.c added, these changes
didn't make it to trunk and the 1.6.x branches
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@257810 f38db490-d61c-443f-a65b-d21fe96a405b
Application arguments within the feature map could possibly contain a comma,
which conflicts with the syntax of the features.conf configuration file. This
patch allows the argument to be wrapped in parentheses or quoted, to allow the
application arguments to be interpreted as a single configuration parameter.
(closes issue #16646)
Reported by: pinga-fogo
Patches:
20100414__issue16646.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
Review: https://reviewboard.asterisk.org/r/547/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@257262 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r257070 | mnicholson | 2010-04-13 11:46:30 -0500 (Tue, 13 Apr 2010) | 9 lines
Add an option to restore past broken behavor of the Events manager action
Before r238915, certain values for the EventMask parameter of the Events action would result in no response being returned. This patch adds an option to restore that broken behavior. Also while fixing this bug I discovered that passing an empty EventMasks parameter would also result in no response being returned, this has been fixed as well while being preserved when the broken behavior is requested.
(closes issue #17023)
Reported by: nblasgen
Review: https://reviewboard.asterisk.org/r/602/
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@257146 f38db490-d61c-443f-a65b-d21fe96a405b
Specifically, the situation would happen when multiple
callers would request CC for a single generically-monitored
device. If the monitored device became available but the
caller did not answer the recall, then there was nothing
that would poke the CC core to let it know that it should
attempt to recall someone else instead.
After careful consideration, I came to the conclusion that
the only area of Asterisk that needed to be touched was the
generic CC monitor. All other types of CC would require something
outside of Asterisk to invoke a recall for a separate device.
This was accomplished by changing the generic monitor destructor
to poke other generic monitor instances if the device is currently
available and the specific instance was currently not suspended.
In order to not accidentally trigger recalls at bad times, the
fit_for_recall flag was also added to the generic_monitor_instance_list
struct. This gets set as soon as a monitored device becomes available.
It gets cleared if a CCNR request triggers the creation of a new
generic monitor instance. By doing this, we don't accidentally try
to recall a device when the monitored device was being monitored
for CCNR and never actually became available for recall in the first
place.
This error was discovered by Steve Pitts during in-house testing
at Digium.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@256985 f38db490-d61c-443f-a65b-d21fe96a405b
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@256528 f38db490-d61c-443f-a65b-d21fe96a405b
From Review Board:
There are two interrelated changes here.
First, there is the introduction of func_srv. This adds two new read-only
dialplan functions, SRVQUERY and SRVRESULT. They work very similarly to the
ENUMQUERY and ENUMRESULT functions, except that this allows one to query SRV
records instead. In order to facilitate this work, I added a couple of new API
calls to srv.h. ast_srv_get_record_count tells the number of records returned
by an SRV lookup. This number is calculated at the time of the SRV lookup.
ast_srv_get_nth_record allows one to get a numbered SRV record.
Second, there is the modification to chan_sip that allows one to specify a
hostname or IP address (along with a port) to send an outgoing INVITE to when
dialing a SIP peer. This goes hand-in-hand with func_srv. You can query SRV
records and then use the host and port from the results to dial via a specific
host instead of what is configured in sip.conf.
Review: https://reviewboard.asterisk.org/r/608
SWP-1200
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@256485 f38db490-d61c-443f-a65b-d21fe96a405b
SWP-1229
ABE-2161
* Ensure chan_local.c:local_call() will not leak cid.cid_dnid when
copying.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@256104 f38db490-d61c-443f-a65b-d21fe96a405b
Some platforms prefix externally-visible symbols in object files generated
from C sources (most commonly, '_' is the prefix). On these platforms,
the existing symbol export filtering process ends up suppressing all the symbols
that are supposed to be left visible. This patch allows the prefix string
to be supplied to the top-level Makefile in the LINKER_SYMBOL_PREFIX variable,
and then generates the linker scripts as required to include the prefix
supplied.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@255906 f38db490-d61c-443f-a65b-d21fe96a405b
application is executing on a channel.
This patch addresses an issue found during working with end-users
using res_fax. If an incoming call is answered in the dialplan, or
jumps to the 'fax' extension due to reception of a CNG tone (with
faxdetect enabled), and then the remote endpoint sends a T.38
re-INVITE, it is possible for the channel's T.38 state to be
'T38_STATE_NEGOTIATING' when the application starts up. Unfortunately,
even if the application wants to use T.38, it can't respond to the
peer's negotiation request, because the AST_CONTROL_T38_PARAMETERS
control frame that chan_sip sent originally has been lost, and the
application needs the content of that frame to be able to formulate a
reply.
This patch adds a new 'request' type to AST_CONTROL_T38_PARAMETERS,
AST_T38_REQUEST_PARMS. If the application sends this request, chan_sip
will re-send the original control frame (with
AST_T38_REQUEST_NEGOTIATE as the request type), and the application
can respond as normal. If this occurs within the five second timeout
in chan_sip, the automatic cancellation of the peer reinvite will be
stopped, and the application will 'own' the negotiation process from
that point onwards.
This also improves the code path in chan_sip to allow sip_indicate(),
when called for AST_CONTROL_T38_PARAMETERS, to be able to return a
non-zero response, which should have been in place before since the
control frame *can* fail to be processed properly. It also modifies
ast_indicate() to return whatever result the channel driver returned
for this control frame, rather than converting all non-zero results
into '-1'. Finally, the new request type intentionally returns a
positive value, so that an application that sends
AST_T38_REQUEST_PARMS can know for certain whether the channel driver
accepted it and will be replying with a control frame of its own, or
whether it was ignored (if the sip_indicate()/ast_indicate() path had
properly supported failure responses before, this would not be
necessary).
This patch also modifies res_fax to take advantage of the new request.
In addition, this patch makes sip_t38_abort() actually lock the
private structure before doing its work... bad programmer, no donut.
This patch also enhances chan_sip's 'faxdetect' support to allow
triggering on T.38 re-INVITEs received as well as CNG tone detection.
Review: https://reviewboard.asterisk.org/r/556/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@254450 f38db490-d61c-443f-a65b-d21fe96a405b
Here is a cut and paste of my review request for this change:
This past weekend, Russell ran our current suite of unit tests for Asterisk
under valgrind. The PBX pattern match test caused valgrind to spew forth two
invalid read errors. This patch contains two changes that shut valgrind up and
do not cause any new memory leaks.
Change 1: In ast_context_remove_extension_callerid2, valgrind reported an
invalid read in the for loop close to the function's end. Specifically, one of
the the strcmp calls in the loop control was reading invalid memory. This was
because the caller of ast_context_remove_extension_callerid2 (__ast_context
destroy in this case) passed as a parameter a shallow copy of an ast_exten's
exten field. This same ast_exten was what was destroyed inside the for loop,
thus any iterations of the for loop beyond the destruction of the ast_exten
would result in invalid reads. My fix for this is to make a copy of the
ast_exten's exten field and pass the copy to
ast_context_remove_extension_callerid2. In addition, I have also acted
similarly with the ast_exten's matchcid field. Since in this case a NULL is
handled quite differently than an empty string, I needed to be a bit more
careful with its handling.
Change 2: In __ast_context_destroy, we iterated over a hashtab and called
ast_context_remove_extension_callerid2 on each item. Specifically, the hashtab
over which we were iterating was an ast_exten's peer_table. Inside of
ast_context_remove_extension_callerid2, we could possibly destroy this
ast_exten, which also caused the hashtab to be freed. Attempting to call
ast_hashtab_end_traversal on the hashtab iterator caused an invalid read to
occur when trying to read the iterator->tab->do_locking field since
iterator->tab had already been freed. My handling of this problem is a bit less
straightforward. With each iteration over the hashtab's contents, we set a
variable called "end_traversal" based on the return of
ast_context_remove_extension_callerid2. If 0 is ever returned, then we know
that the extension was found and destroyed. Because of this, we cannot call
ast_hashtab_end_traversal because we will be guaranteeing a read of invalid
memory. In such a case, we forego calling ast_hashtab_end_traversal and instead
call ast_free on the hashtab iterator.
Review: https://reviewboard.asterisk.org/r/585
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@254362 f38db490-d61c-443f-a65b-d21fe96a405b
This changes native bridging to break one millisecond early so that the more
accurate timeval calculations done in the generic bridge can be performed using
the bridge config. Currently the time between exiting native bridging slightly
late can sometimes cause a large enough discrepancy for warnings to be missed.
For the record, 1.4 does not attempt to native bridge at all when warnings are
enabled.
(closes issue #15815)
Reported by: adomjan
Review: https://reviewboard.asterisk.org/r/577/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@254050 f38db490-d61c-443f-a65b-d21fe96a405b
users expect them to work.
'core set debug' and 'core set verbose' can optionally change the
level for a specific filename; however, this is actually for a
specific source file name, not the module that source file is included
in. With examples like chan_sip, chan_iax2, chan_misdn and others
consisting of multiple source files, this will not lead to the
behavior that users expect. If they want to set the debug level for
chan_sip, they want it set for all of chan_sip, and not to have to
also set it for reqresp_parser and other files that comprise the
chan_sip module.
This patch changes this functionality to be module-name based instead
of file-name based.
To make this work, some Makefile modifications were required to ensure
that the AST_MODULE definition is present in each object file produced
for each module as well.
Review: https://reviewboard.asterisk.org/r/574/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@253917 f38db490-d61c-443f-a65b-d21fe96a405b
We can have bad results when a module, upon being loaded, attempts
to reference the channels container if the container hasn't yet
been initialized. I saw this happen by trying to preload pbx_config.so
and having a hint defined which referenced a non-existent SIP peer.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@253872 f38db490-d61c-443f-a65b-d21fe96a405b
internal_ao2_ref uses INTERNAL_OBJ which mzy report 'bad magic number', but
internal_ao2_ref continues on, causing segfault.
Although AO2_MAGIC number is checked by INTERNAL_OBJ before internal_ao2_ref is
called, A02_MAGIC is being destroyed (or a wrong pointer) by the time
internal_ao2_ref uses INTERNAL_OBJ.
internal_ao2_ref now returns -1 if INTERNAL_OBJ encouters a bad magic number.
(issue #17037)
Reported by: alecdavis
Patches:
bug17037.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@253490 f38db490-d61c-443f-a65b-d21fe96a405b
eliel