When extracting timestamps that are parsed, time stamp values that are not set
(time values of 0.000000) should not actually result in a parsed string. The
value should be skipped, and the result of the CDR function should be an
empty string.
Prior to this patch, the result was fed to the time formatting, which would
result in an output of a date/time in 1969.
........
Merged revisions 407747 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407748 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The per console verbose level feature as previously implemented caused a
large performance penalty. The fix required some minor incompatibilities
if the new rasterisk is used to connect to an earlier version. If the new
rasterisk connects to an older Asterisk version then the root console
verbose level is always affected by the "core set verbose" command of the
remote console even though it may appear to only affect the current
console. If an older version of rasterisk connects to the new version
then the "core set verbose" command will have no effect.
* Fixed the verbose performance by not generating a verbose message if
nothing is going to use it and then filtered any generated verbose
messages before actually sending them to the remote consoles.
* Split the "core set debug" and "core set verbose" CLI commands to remove
the per module verbose support that cannot work with the per console
verbose level.
* Added a silent option to the "core set verbose" command.
* Fixed "core set debug off" tab completion.
* Made "core show settings" list the current console verbosity in addition
to the root console verbosity.
* Changed the default verbose level of the 'verbose' setting in the
logger.conf [logfiles] section. The default is now to once again follow
the current root console level. As a result, using the AMI Command action
with "core set verbose" could again set the root console verbose level and
affect the verbose level logged.
(closes issue AST-1252)
Reported by: Guenther Kelleter
Review: https://reviewboard.asterisk.org/r/3114/
........
Merged revisions 405431 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 405432 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In https://reviewboard.asterisk.org/r/3057/, applications and functions that
manipulate CDRs were made to interact over Stasis. This was done to
synchronize manipulations of CDRs from the dialplan with the updates the
engine itself receives over the message bus.
This change rested on a faulty premise: that messages published to the CDR
topic or to a topic that forwards to the CDR topic are synchronized with the
messages handled by the CDR topic subscription in the CDR engine. This is not
the case. There is no ordering guaranteed for two messages published to the
same topic; ordering is only guaranteed if a message is published to the same
subscriber.
Stasis was modified in r405311 to allow a publisher to synchronize on the
subscriber. This patch uses that API to synchronize the CDR publishers with
the CDR engine message router, which maintains the overall topic subscription.
(closes issue ASTERISK-22884)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3099/
........
Merged revisions 405312 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change is in preparation for external MWI support.
Removed code from the system for normal mailbox handling that appends
@default to the mailbox identifier if it does not have a context. The
only exception is the legacy hasvoicemail users.conf option. The legacy
option will only work for app_voicemail mailboxes. The system cannot make
any assumptions about the format of the mailbox identifer used by
app_voicemail.
chan_sip and chan_dahdi/sig_pri had the most changes because they both
tried to interpret the mailbox identifier. chan_sip just stored and
compared the two components. chan_dahdi actually used the box
information.
The ISDN MWI support configuration options had to be reworked because
chan_dahdi was parsing the box@context format to get the box number. As a
result the mwi_vm_boxes chan_dahdi.conf option was added and is documented
in the chan_dahdi.conf.sample file.
Review: https://reviewboard.asterisk.org/r/3072/
........
Merged revisions 404348 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When doing the rework of the CDR engine that pushed all of the logic into cdr.c
and made it respond to changes in channel state over Stasis, we knew that
accessing the CDR engine from the dialplan would be "slightly"
non-deterministic. Dialplan threads would be accessing CDRs while Stasis
threads would be updating the state of said CDRs - whereas in the past,
everything happened on the dialplan threads. Tests have shown that "slightly"
is in reality "very".
This patch synchronizes things by making the dialplan applications/functions
that manipulate CDRs do so over Stasis. ForkCDR, NoCDR, ResetCDR, CDR, and
CDR_PROP now all use Stasis to send their requests over to the CDR engine,
and synchronize on the channel Stasis topic via a subscription so that they
return their values/control to the dialplan at the appropriate time.
While going through this, the following changes were also made:
* DISA, which can reset the CDR when a user successfully authenticates, now
just uses the ResetCDR app to do this. This prevents having to duplicate
the same Stasis synchronization logic in that application.
* Answer no longer disables CDRs. It actually didn't work anyway - calling
DISABLE on the channel's CDR doesn't stop the CDR from getting the Answer
time - it just kills all CDRs on that channel, which isn't what the caller
would intend.
(closes issue ASTERISK-22884)
(closes issue ASTERISK-22886)
Review: https://reviewboard.asterisk.org/r/3057/
........
Merged revisions 404294 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404295 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Original commit message by mmichelson (asterisk 12 r403311):
"This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such."
The above was initially committed and then reverted at r403398. The problem
was found to be in core_local.c in the publish_local_bridge_message function.
The ast_unreal_lock_all function locks and adds a reference to the returned
channels and while they were being unlocked they were not being unreffed when
no longer needed. Fixed by unreffing the channels.
Also in bridge.c a lock was obtained on "other->chan", but then an attempt was
made to unlock "other" and not the previously locked channel. Fixed by
unlocking "other->chan"
(closes issue ASTERISK-22709)
Reported by: John Bigelow
........
Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch allows individual dialplan functions to be marked as
'dangerous', to inhibit their execution from external sources.
A 'dangerous' function is one which results in a privilege escalation.
For example, if one were to read the channel variable SHELL(rm -rf /)
Bad Things(TM) could happen; even if the external source has only read
permissions.
Execution from external sources may be enabled by setting
'live_dangerously' to 'yes' in the [options] section of asterisk.conf.
Although doing so is not recommended.
Also, the ABI was changed to something more reasonable, since Asterisk
12 does not yet have a public release.
(closes issue ASTERISK-22905)
Review: http://reviewboard.digium.internal/r/432/
........
Merged revisions 403913 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 403917 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 403959 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403960 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds CHANNEL read support for chan_pjsip. This allows the dialplan
to use the CHANNEL function on a chan_pjsip channel to obtain run-time
information about the channel from the PJSIP channel driver and the PJSIP
stack. This includes:
* RTP information, including source/destination media addresses, whether or
not the media is secure, held, and other properties.
* RTCP information. This includes sets of parseable information, as well as
individual statistic attriutes.
* PJSIP information. This includes URIs, local/remote signalling addresses,
whether or not the signalling is secure, and other properties.
* The endpoint name. This can be used in conjunction with the PJSIP_ENDPOINT
function to obtain more detailed endpoint information.
Review: https://reviewboard.asterisk.org/r/3038/
........
Merged revisions 403618 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403619 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such.
........
Merged revisions 403311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AST_CONFIG dialplan function defined in func_config.c allocates its
config file list entries using ast_malloc. List entry allocations
destined for use with Asterisk's linked list API must be ast_calloc()d
or otherwise initialized so that list pointers are set to NULL. These
uses of ast_malloc have been replaced by ast_calloc to prevent
dereferencing of uninitialized pointer values when traversing the list.
(closes issue ASTERISK-22483)
Reported by: Brian Scott
........
Merged revisions 400694 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 400697 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 400701 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400704 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I can only blame this on a bad merge, because this in no way worked properly
the way it was written. Mea culpa. The function should now parse its arguments
correctly and function properly. (Note that the API used by the CDR_PROP
function has working unit tests... this was merely bad coding of the actual
registered function)
(closes issue ASTERISK-22613)
Reported by: Private Name
........
Merged revisions 400196 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line
Minor performance bump by not allocate manager variable struct if we don't need it
........
r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines
Stasis performance improvements
This patch addresses several performance problems that were found in
the initial performance testing of Asterisk 12.
The Stasis dispatch object was allocated as an AO2 object, even though
it has a very confined lifecycle. This was replaced with a straight
ast_malloc().
The Stasis message router was spending an inordinate amount of time
searching hash tables. In this case, most of our routers had 6 or
fewer routes in them to begin with. This was replaced with an array
that's searched linearly for the route.
We more heavily rely on AO2 objects in Asterisk 12, and the memset()
in ao2_ref() actually became noticeable on the profile. This was
#ifdef'ed to only run when AO2_DEBUG was enabled.
After being misled by an erroneous comment in taskprocessor.c during
profiling, the wrong comment was removed.
Review: https://reviewboard.asterisk.org/r/2873/
........
r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines
Taskprocessor optimization; switch Stasis to use taskprocessors
This patch optimizes taskprocessor to use a semaphore for signaling,
which the OS can do a better job at managing contention and waiting
that we can with a mutex and condition.
The taskprocessor execution was also slightly optimized to reduce the
number of locks taken.
The only observable difference in the taskprocessor implementation is
that when the final reference to the taskprocessor goes away, it will
execute all tasks to completion instead of discarding the unexecuted
tasks.
For systems where unnamed semaphores are not supported, a really
simple semaphore implementation is provided. (Which gives identical
performance as the original taskprocessor implementation).
The way we ended up implementing Stasis caused the threadpool to be a
burden instead of a boost to performance. This was switched to just
use taskprocessors directly for subscriptions.
Review: https://reviewboard.asterisk.org/r/2881/
........
r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines
Optimize how Stasis forwards are dispatched
This patch optimizes how forwards are dispatched in Stasis.
Originally, forwards were dispatched as subscriptions that are invoked
on the publishing thread. This did not account for the vast number of
forwards we would end up having in the system, and the amount of work it
would take to walk though the forward subscriptions.
This patch modifies Stasis so that rather than walking the tree of
forwards on every dispatch, when forwards and subscriptions are changed,
the subscriber list for every topic in the tree is changed.
This has a couple of benefits. First, this reduces the workload of
dispatching messages. It also reduces contention when dispatching to
different topics that happen to forward to the same aggregation topic
(as happens with all of the channel, bridge and endpoint topics).
Since forwards are no longer subscriptions, the bulk of this patch is
simply changing stasis_subscription objects to stasis_forward objects
(which, admittedly, I should have done in the first place.)
Since this required me to yet again put in a growing array, I finally
abstracted that out into a set of ast_vector macros in
asterisk/vector.h.
Review: https://reviewboard.asterisk.org/r/2883/
........
r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines
Remove dispatch object allocation from Stasis publishing
While looking for areas for performance improvement, I realized that an
unused feature in Stasis was negatively impacting performance.
When a message is sent to a subscriber, a dispatch object is allocated
for the dispatch, containing the topic the message was published to, the
subscriber the message is being sent to, and the message itself.
The topic is actually unused by any subscriber in Asterisk today. And
the subscriber is associated with the taskprocessor the message is being
dispatched to.
First, this patch removes the unused topic parameter from Stasis
subscription callbacks.
Second, this patch introduces the concept of taskprocessor local data,
data that may be set on a taskprocessor and provided along with the data
pointer when a task is pushed using the ast_taskprocessor_push_local()
call. This allows the task to have both data specific to that
taskprocessor, in addition to data specific to that invocation.
With those two changes, the dispatch object can be removed completely,
and the message is simply refcounted and sent directly to the
taskprocessor.
Review: https://reviewboard.asterisk.org/r/2884/
........
Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made ast_strftime_locale() ensure that the output buffer is initialized.
The std library strftime() returns 0 and does not touch the buffer if it
has an error. However, the function can also return 0 without an error.
(closes issue ASTERISK-22412)
Reported by: rmudgett
........
Merged revisions 397902 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397903 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This removes unused code, event types, IE pltypes, and event IE types
where possible and makes several functions private that were once
public. This includes a renumbering of the remaining event and IE types
which breaks binary compatibility with previous versions. The last
remaining consumers of the old event system (or parts thereof) are
main/security_events.c, res/res_security_log.c, tests/test_cel.c,
tests/test_event.c, main/cel.c, and the CEL backends.
Review: https://reviewboard.asterisk.org/r/2703/
(closes issue ASTERISK-22139)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch implements the controls from ARI recordings. The controls
are:
* DELETE /recordings/live/{recordingName} - stop recording and
discard it
* POST /recordings/live/{recordingName}/stop - stop recording
* POST /recordings/live/{recordingName}/pause - pause recording
* POST /recordings/live/{recordingName}/unpause - resume recording
* POST /recordings/live/{recordingName}/mute - mute recording (record
silence to the file)
* POST /recordings/live/{recordingName}/unmute - unmute recording.
Since this underlying functionality did not already exist, is was
added to app.c by a set of control frames, similar to how playback
control works. The pause/mute control frames are toggles, even though
the ARI controls are idempotent, to be consistent with the playback
control frames.
(closes issue ASTERISK-22181)
Review: https://reviewboard.asterisk.org/r/2697/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is smaller than the initial review placed on review board. This is because
a change to allow for channel drivers to access parking functionality externally was
committed and invalidated quite a few of the changes initially made.
(closes issue ASTERISK-22039)
reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2717
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents XML documentation duplication by expanding channel and
bridge snapshot tags into channel and bridge snapshot parameter sets
with a given prefix or defaulting to no prefix. This also prevents
documentation from becoming fractured and out of date by keeping all
variations of the documentation in template form such that it only
needs to be updated once and keeps maintenance to a minimum.
Review: https://reviewboard.asterisk.org/r/2708/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395985 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch renames the bridging* files to bridge*. This may seem pedantic
and silly, but it fits better in line with current Asterisk naming conventions:
* channel is not "channeling"
* monitor is not "monitoring"
etc.
A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is
the act of using a bridge on a set of channels - and the API that fulfills that
role is more than just the action.
(closes issue ASTERISK-22130)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is not apparent to the average user that the PASSTHRU function should not
be passed as ${PASSTHRU(string)} but just as PASSTHRU(string) to functions
which take a variable name and not its contents.
This patch clarifies the behavior in the documentation and provides an example.
(closes issue ASTERISK-21717)
Reported by: Richard Miller
patches:
func_strings.diff uploaded by Richard Miller (license 5685)
........
Merged revisions 394302 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 394303 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When func_cdr is used for variable substitution, there is no channel name
and hence no run-time information available for CDR variable substitution.
In that case, the correct thing to do is to use the CDR object on the channel
passed to the function. This patch checks to see if the channel passed in
has a name - if not, it uses ast_cdr_format_var instead of ast_cdr_get_var.
This allows CDR backends to continue to use variable substitution in order to
resolve ast_cdr object properties.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392214 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The type of tv_usec is suseconds_t. On Linux, this is usually a long int, but
the specification is actually pretty lax on what it might actually be. And,
sadly, there's no printf/scanf width specifier for suseconds_t. So it could
bit an int or a long, but there's not a great way to tell which it is.
This patch fixes scanf by reading into a long temporary variable that's then
stored into the tv_usec. It fixes printf by casting the tv_usec to a long
first.
This patch also adds some missing width specifiers for some debug statements,
which would cause ".000001" to be displayed at ".1".
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392076 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the initial push to update Asterisk's CDR engine for the new
bridging framework. This patch guts the existing CDR engine and builds the new
on top of messages coming across Stasis. As changes in channel state and bridge
state are detected, CDRs are built and dispatched accordingly. This
fundamentally changes CDRs in a few ways.
(1) CDRs are now *very* reflective of the actual state of channels and bridges.
This means CDRs track well with what an actual channel is doing - which
is useful in transfer scenarios (which were previously difficult to pin
down). It does, however, mean that CDRs cannot be 'fooled'. Previous
behavior in Asterisk allowed for CDR applications, channels, and other
properties to be spoofed in parts of the code - this no longer works.
(2) CDRs have defined behavior in multi-party scenarios. This behavior will not
be what everyone wants, but it is a defined behavior and as such, it is
predictable.
(3) The CDR manipulation functions and applications have been overhauled. Major
changes have been made to ResetCDR and ForkCDR in particular. Many of the
options for these two applications no longer made any sense with the new
framework and the (slightly) more immutable nature of CDRs.
There are a plethora of other changes. For a full description of CDR behavior,
see the CDR specification on the Asterisk wiki.
(closes issue ASTERISK-21196)
Review: https://reviewboard.asterisk.org/r/2486/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Breaks many things until they can be reworked. A partial list:
chan_agent
chan_dahdi, chan_misdn, chan_iax2 native bridging
app_queue
COLP updates
DTMF attended transfers
Protocol attended transfers
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r388005, macros were introduced to consistently define message
types. This added an assert if a message type was used either before
it was initialized or after it had been cleaned up. It turns out that
this assertion fires during shutdown.
This actually exposed a hidden shutdown ordering problem. Since
unsubscribing is asynchronous, it's possible that the message types
used by the subscription could be freed before the final message of
the subscription was processed.
This patch adds stasis_subscription_join(), which blocks until the
last message has been processed by the subscription. Since joining was
most commonly done right after an unsubscribe, a
stasis_unsubscribe_and_join() convenience function was also added.
Similar functions were also added to the stasis_caching_topic and
stasis_message_router, since they wrap subscriptions and have similar
problems.
Other code in trunk was refactored to join() where appropriate, or at
least verify that the subscription was complete before being
destroyed.
Review: https://reviewboard.asterisk.org/r/2540
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch removes the direct call to AMI from the SHARED function
and instead call Stasis-Core. Stasis-Core delivers the notification
that a shared variable has changed on a channel to all interested
consumers.
(issue ASTERISK-21462)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387630 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes a crash in Asterisk that could be caused by using the
PresenceState AMI action while providing an invalid provider. This patch
also adds some additional warnings when a user attempts to provide the
PresenceState action with invalid data, and removes some NOTICE statements
that were still lurking in the code from testing.
(closes issue AST-1084)
Reported by: John Bigelow
Tested by: John Bigelow
........
Merged revisions 381594 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381595 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the capability for asynchronous manipulation of audio being
played back to a channel though a new AMI action "ControlPlayback". The
ControlPlayback action supports a number of operations, the availability of
which depend on the application being used to send audio to the channel.
When the audio playback was initiated using the ControlPlayback application
or CONTROL STREAM FILE AGI command, the audio can be paused, stopped,
restarted, reversed, or skipped forward. When initiated by other mechanisms
(such as the Playback application), the audio can be stopped, reversed, or
skipped forward.
Review: https://reviewboard.asterisk.org/r/2265/
(closes issue ASTERISK-20882)
Reported by: mjordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379830 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
........
Merged revisions 378376 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378377 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
........
Merged revisions 378321 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378322 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Currently, if an acknowledgement of a timer fails Asterisk will not realize
that a serious error occurred and will continue attempting to use the timer's
file descriptor. This can lead to situations where errors stream to the
CLI/log file. This consumes significant resources, masks the actual problem
that occurred (whatever caused the timer to fail in the first place), and
can leave channels in odd states.
This patch propagates the errors in the timing resource modules up through
the timer core, and makes users of these timers handle acknowledgement
failures. It also adds some defensive coding around the use of timers
to prevent using bad file descriptors in off nominal code paths.
Note that the patch created by the issue reporter was modified slightly for
this commit and backported to 1.8, as it was originally written for
Asterisk 10.
Review: https://reviewboard.asterisk.org/r/2178/
(issue ASTERISK-20032)
Reported by: Jeremiah Gowdy
patches:
jgowdy-timerfd-6-22-2012.diff uploaded by Jeremiah Gowdy (license 6358)
........
Merged revisions 375893 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 375894 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 375895 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375896 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update title that was left behind many years ago. Used revision 6596 as my guide for what it should be.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This allows for the REDIRECTING dialplan function to be
used to set the reason to any string.
The SIP channel driver has been modified to set the redirecting
reason string to the value received in a Diversion header. In
addition, SIP 480 response reason text will set the redirecting
reason as well.
(closes issue AST-942)
reported by Malcolm Davenport
(closes issue AST-943)
reported by Malcolm Davenport
Review: https://reviewboard.asterisk.org/r/2101
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Doxygen updates including mistakes, misspellings, missing parameters, updates for Doxygen style. Some missing txt file links are removed but their content or essense will be included in some later updates. A majority of the txt files were removed in the 1.6 era but never noted. The HR and EXTREF are simple changes that make the documentation more compatable with more versions of Doxygen.
Further updates coming.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373330 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* ASTERISK-20383
Missing named call pickup group features:
CHANNEL(callgroup) - Need CHANNEL(namedcallgroup)
CHANNEL(pickupgroup) - Need CHANNEL(namedpickupgroup)
Pickup() - Needs to also select from named pickup groups.
* ASTERISK-20384
Using the pickupexten, the pickup channel selection could fail even though
there was a call it could have picked up. In a call pickup race when
there are multiple calls to pickup and two extensions try to pickup a
call, it is conceivable that the loser will not pick up any call even
though it could have picked up the next oldest matching call.
Regression because of the named call pickup group feature.
* See ASTERISK-20386 for the implementation improvements. These are the
changes in channel.c and channel.h.
* Fixed some locking issues in CHANNEL().
(closes issue ASTERISK-20383)
Reported by: rmudgett
(closes issue ASTERISK-20384)
Reported by: rmudgett
(closes issue ASTERISK-20386)
Reported by: rmudgett
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/2112/
........
Merged revisions 373220 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373221 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The name of the "HangupCauseClear" application is "HangupCauseClear",
not "HangupcauseClear". The incorrect case of 'cause' caused the
XML documentation to not register properly.
As an aside, this commit message felt very awkward, but I'm not sure
how else to note that "X", which has to be "X", was referred to as "x".
(closes issue ASTERISK-20253)
Reported by: Andrew Latham
Patches:
hangupcause.diff uploaded by Andrew Latham (license #5985)
........
Merged revisions 371516 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371517 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the feature "Private representation of caller, connected
and redirecting party ids", as previously discussed with us (DATUS) and
Digium.
1. Feature motivation
Until now it is quite difficult to modify a party number or name which can
only be seen by exactly one particular instantiated technology channel
subscriber. One example where a modified party number or name on one
channel is spread over several channels are supplementary services like
call transfer or pickup. To implement these features Asterisk internally
copies caller and connected ids from one channel to another. Another
example are extension subscriptions. The monitoring entities (watchers)
are notified of state changes and - if desired - of party numbers or names
which represent the involving call parties. One major feature where a
private representation of party names is essentially needed, i.e. where a
party name shall be exclusively signaled to only one particular user, is a
private user-specific name resolution for party numbers. A lookup in a
private destination-dependent telephone book shall provide party names
which cannot be seen by any other user at any time.
2. Feature Description
This feature comes along with the implementation of additional private
party id elements for caller id, connected id and redirecting ids inside
Asterisk channels.
The private party id elements can be read or set by the user using
Asterisk dialplan functions.
When a technology channel is initiating a call, receives an internal
connected-line update event, or receives an internal redirecting update
event, it merges the corresponding public id with the private id to create
an effective party id. The effective party id is then used for protocol
signaling.
The channel technologies which initially support the private id
representation with this patch are SIP (chan_sip), mISDN (chan_misdn) and
PRI (chan_dahdi).
Once a private name or number on a channel is set and (implicitly) made
valid, it is generally used for any further protocol signaling until it is
rewritten or invalidated.
To simplify the invalidation of private ids all internally generated
connected/redirecting update events and also all connected/redirecting
update events which are generated by technology channels -- receiving
regarding protocol information - automatically trigger the invalidation of
private ids.
If not using the private party id representation feature at all, i.e. if
using only the 'regular' caller-id, connected and redirecting related
functions, the current characteristic of Asterisk is not affected by the
new extended functionality.
3. User interface Description
To grant access to the private name and number representation from the
Asterisk dialplan, the CALLERID, CONNECTEDLINE and REDIRECTING dialplan
functions are extended by the following data types. The formats of these
data types are equal to the corresponding regular 'non-private' already
existing data types:
CALLERID:
priv-all
priv-name priv-name-valid priv-name-charset priv-name-pres
priv-num priv-num-valid priv-num-plan priv-num-pres
priv-subaddr priv-subaddr-valid priv-subaddr-type priv-subaddr-odd
priv-tag
CONNECTEDLINE:
priv-name priv-name-valid priv-name-pres priv-name-charset
priv-num priv-num-valid priv-num-pres priv-num-plan
priv-subaddr priv-subaddr-valid priv-subaddr-type priv-subaddr-odd
priv-tag
REDIRECTING:
priv-orig-name priv-orig-name-valid priv-orig-name-pres priv-orig-name-charset
priv-orig-num priv-orig-num-valid priv-orig-num-pres priv-orig-num-plan
priv-orig-subaddr priv-orig-subaddr-valid priv-orig-subaddr-type priv-orig-subaddr-odd
priv-orig-tag
priv-from-name priv-from-name-valid priv-from-name-pres priv-from-name-charset
priv-from-num priv-from-num-valid priv-from-num-pres priv-from-num-plan
priv-from-subaddr priv-from-subaddr-valid priv-from-subaddr-type priv-from-subaddr-odd
priv-from-tag
priv-to-name priv-to-name-valid priv-to-name-pres priv-to-name-charset
priv-to-num priv-to-num-valid priv-to-num-pres priv-to-num-plan
priv-to-subaddr priv-to-subaddr-valid priv-to-subaddr-type priv-to-subaddr-odd
priv-to-tag
Reported by: Thomas Arimont
Review: https://reviewboard.asterisk.org/r/2030/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch includes the following:
* Unit tests for the abstract Jitter Buffer API. This includes both fixed
and adaptive flavors, testing nominal creation, frame input, frame retrieval,
resyncing; off nominal frame input overflow, out of order, and others.
* Tweaks to the abstract_jb API to remove the unnecessary resync_threshold
parameter from the create function (resync_threshold is already in the
struct passed into the create function)
* Ensure the fixed jitter buffer is empty before destroying it, to avoid an
ASSERT
* Don't "resync" the adaptive jitter buffer. The mechanism that was being
used actually causes the jitter buffer to think its being overflowed by going
around the jitterbuf API and attempting to 'resynch' it improperly. If a
resync is needed, the jitter buffer will do it properly by itself. Note that
this is only an optimization needed for trunk, as the worst that happens is
the loss of three voice packets before the adaptive jitter buffer will resync
anyway.
Review: https://reviewboard.asterisk.org/r/2035
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370387 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The HANGUPCAUSE hash (trunk only) meant to replace SIP_CAUSE has now
been replaced with the HANGUPCAUSE and HANGUPCAUSE_KEYS dialplan
functions to better facilitate access to the AST_CAUSE translations
for technology-specific cause codes. The HangupCauseClear application
has also been added to remove this data from the channel.
(closes issue SWP-4738)
Review: https://reviewboard.asterisk.org/r/2025/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370316 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The documentation for DEC in func_math.c was incorrect. Looks like a copy and
paste error.
(Closes issue ASTERISK-20095)
Reported by: Billy Chia
Tested by: Michael L. Young
Patches:
func_math.patch uploaded by Billy Chia (license 6381)
........
Merged revisions 369970 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369972 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Hangup handlers are an alternative to the h extension. They can be used
in addition to the h extension. The idea is to attach a Gosub routine to
a channel that will execute when the call hangs up. Whereas which h
extension gets executed depends on the location of dialplan execution when
the call hangs up, hangup handlers are attached to the call channel. You
can attach multiple handlers that will execute in the order of most
recently added first.
(closes issue ASTERISK-19549)
Reported by: Mark Murawski
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/2002/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369493 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r369001 | kpfleming | 2012-06-15 10:56:08 -0500 (Fri, 15 Jun 2012) | 11 lines
Add support-level indications to many more source files.
Since we now have tools that scan through the source tree looking for files
with specific support levels, we need to ensure that every file that is
a component of a 'core' or 'extended' module (or the main Asterisk binary)
is explicitly marked with its support level. This patch adds support-level
indications to many more source files in tree, but avoids adding them to
third-party libraries that are included in the tree and to source files
that don't end up involved in Asterisk itself.
........
r369002 | kpfleming | 2012-06-15 10:57:14 -0500 (Fri, 15 Jun 2012) | 3 lines
Add a script to enable finding source files without support-levels defined.
........
Merged revisions 369001-369002 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369005 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was discovered by trying to perform a call forward to an extension
that makes use of func_volume. When the local channel is optimized away,
the datastore on the local;2 channel would have its audiohook destroyed
rather than detaching the audiohook from the channel and then destroying
it.
With this patch, func_volume's datastore destructor takes the proper
route of detaching the audiohook and then destroying it.
(closes issue ASTERISK-19611)
reported by Volker Sauer
Patches:
ASTERISK-19611.patch uploaded by Mark Michelson (license #5049)
........
Merged revisions 368898 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368899 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368900 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Presence support has been added. This is accomplished by
allowing for presence hints in addition to device state
hints. A dialplan function called PRESENCE_STATE has been
added to allow for setting and reading presence. Presence
can be transmitted to Digium phones using custom XML
elements in a PIDF presence document.
Voicemail has new APIs that allow for moving, removing,
forwarding, and playing messages. Messages have had a new
unique message ID added to them so that the APIs will work
reliably. The state of a voicemail mailbox can be obtained
using an API that allows one to get a snapshot of the mailbox.
A voicemail Dialplan App called VoiceMailPlayMsg has been
added to be able to play back a specific message.
Configuration hooks have been added. Configuration hooks
allow for a piece of code to be executed when a specific
configuration file is loaded by a specific module. This is
useful for modules that are dependent on the configuration
of other modules.
chan_sip now has a public method that allows for a custom
SIP INFO request to be sent mid-dialog. Digium phones use
this in order to display progress bars when files are played.
Messaging support has been expanded a bit. The main
visible difference is the addition of an AMI action
MessageSend.
Finally, a ParkingLots manager action has been added in order
to get a list of parking lots.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds to what was fixed in r366880. Specifically, it addresses the
following:
* chan_sip: dispose of an allocated frame in off nominal code paths in
sip_rtp_read
* func_odbc: when disposing of an allocated resultset, ensure that any rows
that were appended to that resultset are also disposed of
* cli: free the created return string buffer in another off nominal code
path
* chan_dahdi: free a frame that was allocated by the dsp layer if we choose
not to process that frame
(issue ASTERISK-19665)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1922/
........
Merged revisions 366944 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366948 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366955 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses a number of memory leaks in a variety of modules that were
found by a static analysis tool. A brief summary of the changes:
* app_minivm: free ast_str objects on off nominal paths
* app_page: free the ast_dial object if the requested channel technology
cannot be appended to the dialing structure
* app_queue: if a penalty rule failed to match any existing rule list
names, the created rule would not be inserted and its memory
would be leaked
* app_read: dispose of the created silence detector in the presence of
off nominal circumstances
* app_voicemail: dispose of an allocated unique ID field for MWI event
un-subscribe requests in off nominal paths; dispose of
configuration objects when using the secret.conf option
* chan_dahdi: dispose of the allocated frame produced by ast_dsp_process
* chan_iax2: properly unref peer in CLI command "iax2 unregister"
* chan_sip: dispose of the allocated frame produced by sip_rtp_read's
call of ast_dsp_process; free memory in parse unit tests
* func_dialgroup: properly deref ao2 object grhead in nominal path of
dialgroup_read
* func_odbc: free resultset in off nominal paths of odbc_read
* cli: free match_list in off nominal paths of CLI match completion
* config: free comment_buffer/list_buffer when configuration file load
is unchanged; free the same buffers any time they were
created and config files were processed
* data: free XML nodes in various places
* enum: free context buffer in off nominal paths
* features: free ast_call_feature in off nominal paths of applicationmap
config processing
* netsock2: users of ast_sockaddr_resolve pass in an ast_sockaddr struct
that is allocated by the method. Failures in
ast_sockaddr_resolve could result in the users of the method
not knowing whether or not the buffer was allocated. The
method will now not allocate the ast_sockaddr struct if it
will return failure.
* pbx: cleanup hash table traversals in off nominal paths; free
ignore pattern buffer if it already exists for the specified
context
* xmldoc: cleanup various nodes when we no longer need them
* main/editline: various cleanup of pointers not being freed before being
assigned to other memory, cleanup along off nominal paths
* menuselect/mxml: cleanup of value buffer for an attribute when that attribute
did not specify a value
* res_calendar*: responses are allocated via the various *_request method
returns and should not be allocated in the various
write_event methods; ensure attendee buffer is freed if no
data exists in the parsed node; ensure that calendar objects
are de-ref'd appropriately
* res_jabber: free buffer in off nominal path
* res_musiconhold: close the DIR* object in off nominal paths
* res_rtp_asterisk: if we run out of ports, close the rtp socket object and free
the rtp object
* res_srtp: if we fail to create the session in libsrtp, destroy the
temporary ast_srtp object
(issue ASTERISK-19665)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1922
........
Merged revisions 366880 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366881 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is the starting point for the Asterisk 11: Who Hung Up work and provides
a framework which will allow channel drivers to report the types of hangup
cause information available in SIP_CAUSE without incurring the overhead of the
MASTER_CHANNEL dialplan function. The initial implementation only includes
cause generation for chan_sip and does not include cause code translation
utilities.
This change deprecates SIP_CAUSE and replaces its method of reporting cause
codes with the new framework. This change also deprecates the 'storesipcause'
option in sip.conf.
Review: https://reviewboard.asterisk.org/r/1822/
(Closes issue SWP-4221)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This resolves core findings from ASTERISK-19650 numbers 0-2, 6, 7, 9-11, 14-20,
22-24, 28, 30-32, 34-36, 42-56, 82-84, 87, 89-90, 93-102, 104, 105, 109-111,
and 115. Finding numbers 26, 33, and 29 were already resolved. Those skipped
were either extended/deprecated or in areas of code that shouldn't be
disturbed.
(Closes issue ASTERISK-19650)
........
Merged revisions 366167 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366168 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Most of the changes here are trivial NULL checks. There are a couple
optimizations to remove the need to check for NULL and outboundproxy parsing
in chan_sip.c was rewritten to avoid use of strtok. Additionally, a bug was
found and fixed with the parsing of outboundproxy when "outboundproxy=," was
set.
(Closes issue ASTERISK-19654)
........
Merged revisions 365398 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365399 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As it turned out, this wasn't a huge deal. We were calling
ast_app_parse_options() for a set of options of which none
took arguments. The proper thing to do for this case is to
pass NULL for the "args" parameter here. We were instead passing
a seemingly-randomly chosen char * from the function. While this
would never get written to, you can rest assured things would
have gotten bad had new options (which took arguments) been added
to func_volume.
(closes issue ASTERISK-19656)
........
Merged revisions 364899 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364900 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364901 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ISDN ETSI PTP and Q.SIG (And SS7 in future) have support for reporting who
was the original redirecting party of a call.
* Added support for the original redirecting party and reason to the
REDIRECTING function and the system core as well as to the stubbed
locations in sig_pri.c.
Review: https://reviewboard.asterisk.org/r/1829/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362779 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In a variety of locations in both reading and writing a file, the result
from the C library function ftello is used as input to other functions. For
the parameters and functions in question, a negative value is invalid input.
This patch checks the return value from the ftello function to determine if
we were able to determine the current position in the file stream and, if not,
fail gracefully.
(issue ASTERISK-19655)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1863/
........
Merged revisions 362355 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362356 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362358 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the global_curl_info data structure could not be allocated, the
datastore associated with the operation would be free'd, but the function
would not return. This would later dereference the datastore, almost
certainly causing Asterisk to crash. With this patch, if the data
structure is not allocated the method will return an error code, and
not attempt any further operation.
........
Merged revisions 361753 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 361754 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361755 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the SHARED function modifies a variable, it removes it from its list of
variables and reinserts the new value at the head of the list of variables.
Doing this inside a standard list traversal can be dangerous, as the
standard list traversal does not account for the list being changed. While
the code in question should not cause a use after free violation due to its
breaking out of the loop after freeing the variable, it could lead to a
maintenance issue if the loop was modified. This also fixes a violation
reported by a static analysis tool, which also makes this code easier to
maintain in the future.
........
Merged revisions 361657 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 361658 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361659 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change restores functionality that was present in 1.4, when AEL macros
were implemented with the Macro dialplan application. Macros are fraught with
functionality issues, because they consume a large portion of the underlying
application stack. This limits the ability of AEL users to call many layers
of subroutines, an issue which Gosub does not have (originally tested to
100,000 levels deep). Therefore, starting in 1.6.0, AEL macros were
implemented with Gosub.
However, there were some implicit behaviors of Macro, which were not replicated
at the same time as with the transition to Gosub, one of which is documented in
the related issue. In particular, the "h" extension is designed to execute not
in the Macro context, but in the topmost calling context. Due to legacy issues
with a misapplied bugfix many years ago, when a macro exited in 1.4, it looks
in all calling contexts, bubbling up from the deepest level until it finds an
"h" extension.
Since AEL hides the complexity of the underlying dialplan logic from the AEL
programmer, it's reasonable to assume that this behavior should not change in
the transition from Asterisk 1.4 LTS to Asterisk 1.8 LTS, lest we break
working AEL configurations in the transition to Asterisk 1.8 LTS. This fix
is the result, which implements a search for the "h" extension in all calling
Gosub contexts.
Fixes ASTERISK-19336
Patch: 20120308__ael_bugfix_for_trunk__2.diff (License #5003) by Tilghman Lesher
(with slight modifications for 1.8)
Tested by: Johan Wilfer
Review: https://reviewboard.asterisk.org/r/1776/
........
Merged revisions 358810 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 358811 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@358812 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change permits each verbose destination (consoles, logger) to have its
own concept of what the verbosity level is. The big feature here is that
the logger will now be able to capture a particular verbosity level without
condemning each console to need to suffer that level of verbosity.
Additionally, a stray 'core set verbose' will no longer change what will go
to the log.
Review: https://reviewboard.asterisk.org/r/1599/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@355413 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Continue channel opaque-ification by wrapping all of the stringfields.
Eventually, we will restrict what can actually set these variables, but
the purpose for now is to hide the implementation and keep people from
adding code that directly accesses the channel structure. Semantic
changes will follow afterward.
Review: https://reviewboard.asterisk.org/r/1661/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are many benefits to making the ast_channel an opaque handle, from
increasing maintainability to presenting ways to kill masquerades. This patch
kicks things off by taking things a field at a time, renaming the field to
'__do_not_use_${fieldname}' and then writing setters/getters and converting the
existing code to using them. When all fields are done, we can move ast_channel
to a C file from channel.h and lop off the '__do_not_use_'.
This patch sets up main/channel_interal_api.c to be the only file that actually
accesses the ast_channel's fields directly. The intent would be for any API
functions in channel.c to use the accessor functions. No more monkeying around
with channel internals. We should use our own APIs.
The interesting changes in this patch are the addition of
channel_internal_api.c, the moving of the AST_DATA stuff from channel.c to
channel_internal_api.c (note: the AST_DATA stuff will have to be reworked to
use accessor functions when ast_channel is really opaque), and some re-working
of the way channel iterators/callbacks are handled so as to avoid creating fake
ast_channels on the stack to pass in matching data by directly accessing fields
(since "name" is a stringfield and the fake channel doesn't init the
stringfields, you can't use the ast_channel_name_set() function). I went with
ast_channel_name(chan) for a getter, and ast_channel_name_set(chan, name) for a
setter.
The majority of the grunt-work for this change was done by writing a semantic
patch using Coccinelle ( http://coccinelle.lip6.fr/ ).
Review: https://reviewboard.asterisk.org/r/1655/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r337974 | rmudgett | 2011-09-26 14:35:23 -0500 (Mon, 26 Sep 2011) | 37 lines
Merged revisions 337973 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r337973 | rmudgett | 2011-09-26 14:30:39 -0500 (Mon, 26 Sep 2011) | 30 lines
Fix deadlock when using dummy channels.
Dummy channels created by ast_dummy_channel_alloc() should be destoyed by
ast_channel_unref(). Using ast_channel_release() needlessly grabs the
channel container lock and can cause a deadlock as a result.
* Analyzed use of ast_dummy_channel_alloc() and made use
ast_channel_unref() when done with the dummy channel. (Primary reason for
the reported deadlock.)
* Made app_dial.c:dial_exec_full() not call ast_call() holding any channel
locks. Chan_local could not perform deadlock avoidance correctly.
(Potential deadlock exposed by this issue. Secondary reason for the
reported deadlock since the held lock was part of the deadlock chain.)
* Fixed some uses of ast_dummy_channel_alloc() not checking the returned
channel pointer for failure.
* Fixed some potential chan=NULL pointer usage in func_odbc.c. Protected
by testing the bogus_chan value.
* Fixed needlessly clearing a 1024 char auto array when setting the first
char to zero is enough in manager.c:action_getvar().
(closes issue ASTERISK-18613)
Reported by: Thomas Arimont
Patches:
jira_asterisk_18613_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: Thomas Arimont
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@337975 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
........
r337119 | rmudgett | 2011-09-20 17:47:45 -0500 (Tue, 20 Sep 2011) | 16 lines
Fix crash with STRREPLACE function.
The ast_func_read() function calls the .read2 callback with the len
parameter set to zero indicating no size restrictions on the supplied
ast_str buffer. The value was used to dimension a local starts[] array
with the array subsequently used.
* Reworked the strreplace() function to perform the string replacement in
a straight forward manner. Eliminated the need for the starts[] array.
(closes issue ASTERISK-18545)
Reported by: Federico Alves
Patches:
jira_asterisk_18545_v10.patch (license #5621) patch uploaded by rmudgett
Tested by: rmudgett, Federico Alves
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@337123 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r335078 | mjordan | 2011-09-09 11:27:01 -0500 (Fri, 09 Sep 2011) | 29 lines
Merged revisions 335064 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r335064 | mjordan | 2011-09-09 11:09:09 -0500 (Fri, 09 Sep 2011) | 23 lines
Updated SIP 484 handling; added Incomplete control frame
When a SIP phone uses the dial application and receives a 484 Address
Incomplete response, if overlapped dialing is enabled for SIP, then
the 484 Address Incomplete is forwarded back to the SIP phone and the
HANGUPCAUSE channel variable is set to 28. Previously, the Incomplete
application dialplan logic was automatically triggered; now, explicit
dialplan usage of the application is required.
Additionally, this patch adds a new AST_CONTOL_FRAME type called
AST_CONTROL_INCOMPLETE. If a channel driver receives this control frame,
it is an indication that the dialplan expects more digits back from the
device. If the device supports overlap dialing it should attempt to
notify the device that the dialplan is waiting for more digits; otherwise,
it can handle the frame in a manner appropriate to the channel driver.
(closes issue ASTERISK-17288)
Reported by: Mikael Carlsson
Tested by: Matthew Jordan
Review: https://reviewboard.asterisk.org/r/1416/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@335079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ENUM dialplan functions do not report DNS query errors properly. It is
useful to differentiate between failed query (e.g. non-existent domain) vs. no
data records of the appropriate type. This is required to make overlapped
dialing work.
(closes issue ASTERISK-13769)
Review: https://reviewboard.asterisk.org/r/1355/
Patch-by: Timo Teras
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@331201 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r326411 | tilghman | 2011-07-05 17:08:29 -0500 (Tue, 05 Jul 2011) | 14 lines
Add the attribute "type" to each "<use>" for menuselect.
This matters only when autoconf fails to detect that weak linking is supported.
External optional dependencies will become optional in both cases, as they are
removed at compile time when not detected. However, runtime-optional modules
are made mandatory when weak linking is not found. This change affects only
the external optional dependencies; previously, they were incorrectly required
when weak linking support was not detected.
Patches:
20110702__issue18062__asterisk_trunk.diff.txt by tilghman (License #5003)
Tested by: iasgoscouk
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@326412 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r309445 | rmudgett | 2011-03-04 09:22:04 -0600 (Fri, 04 Mar 2011) | 46 lines
Get real channel of a DAHDI call.
Starting with Asterisk v1.8, the DAHDI channel name format was changed for
ISDN calls to: DAHDI/i<span>/<number>[:<subaddress>]-<sequence-number>
There were several reasons that the channel name had to change.
1) Call completion requires a device state for ISDN phones. The generic
device state uses the channel name.
2) Calls do not necessarily have B channels. Calls placed on hold by an
ISDN phone do not have B channels.
3) The B channel a call initially requests may not be the B channel the
call ultimately uses. Changes to the internal implementation of the
Asterisk master channel list caused deadlock problems for chan_dahdi if it
needed to change the channel name. Chan_dahdi no longer changes the
channel name.
4) DTMF attended transfers now work with ISDN phones because the channel
name is "dialable" like the chan_sip channel names.
For various reasons, some people need to know which B channel a DAHDI call
is using.
* Added CHANNEL(dahdi_span), CHANNEL(dahdi_channel), and
CHANNEL(dahdi_type) so the dialplan can determine the B channel currently
in use by the channel. Use CHANNEL(no_media_path) to determine if the
channel even has a B channel.
* Added AMI event DAHDIChannel to associate a DAHDI channel with an
Asterisk channel so AMI applications can passively determine the B channel
currently in use. Calls with "no-media" as the DAHDIChannel do not have
an associated B channel. No-media calls are either on hold or
call-waiting.
(closes issue #17683)
Reported by: mrwho
Tested by: rmudgett
(closes issue #18603)
Reported by: arjankroon
Patches:
issue17683_18603_v1.8_v2.patch uploaded by rmudgett (license 664)
Tested by: stever28, rmudgett
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309446 65c4cc65-6c06-0410-ace0-fbb531ad65f3
-Functional changes
1. Dynamic global format list build by codecs defined in codecs.conf
2. SILK 8khz, 12khz, 16khz, and 24khz with custom attributes defined in codecs.conf
3. Negotiation of SILK attributes in chan_sip.
4. SPEEX 32khz with translation
5. SLINEAR 8khz, 12khz, 24khz, 32khz, 44.1khz, 48khz, 96khz, 192khz with translation
using codec_resample.c
6. Various changes to RTP code required to properly handle the dynamic format list
and formats with attributes.
7. ConfBridge now dynamically jumps to the best possible sample rate. This allows
for conferences to take advantage of HD audio (Which sounds awesome)
8. Audiohooks are no longer limited to 8khz audio, and most effects have been
updated to take advantage of this such as Volume, DENOISE, PITCH_SHIFT.
9. codec_resample now uses its own code rather than depending on libresample.
-Organizational changes
Global format list is moved from frame.c to format.c
Various format specific functions moved from frame.c to format.c
Review: https://reviewboard.asterisk.org/r/1104/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@308582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Pass a MCID request to the bridged channel so the bridged channel can send
it to the network.
The ability to send the MCID request on an ISDN span is enabled with the
new chan_dahdi.conf mcid_send option.
JIRA SWP-2845
JIRA ABE-2736
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306755 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the foundation of an entire new way of looking at media in Asterisk.
The code present in this patch is everything required to complete phase1 of my
Media Architecture proposal. For more information about this project visit the link below.
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal
The primary function of this patch is to convert all the usages of format
bitfields in Asterisk to use the new format and format_cap APIs. Functionally
no change in behavior should be present in this patch. Thanks to twilson
and russell for all the time they spent reviewing these changes.
Review: https://reviewboard.asterisk.org/r/1083/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
