The lonely flag is an optional flag for bridge channels that will
make them leave a bridge when a channel leaves if only lonely
channels are in the bridge at that point. This is useful for things
like ending recording and playback channels when they cease to be
interacting with other channels in the bridge.
(closes issue ASTERISK-22117)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2721/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Changed ast_manager_build_bridge_state_string() to assume an empty
prefix string just like ast_manager_build_channel_state_string().
* Created ast_manager_build_bridge_state_string_prefix() to work just like
ast_manager_build_channel_state_string_prefix().
* Made BridgeMerge AMI event use To/From prefixes.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does three things:
1. It provides a Surrogate channel technology with a consolidated
"implementation detail flag" on the channel technology. This tells
consumers of Stasis that the creation of this channel is an implementation
detail in Asterisk and can be ignored (if they so choose). This
consolidates the conference recorder/announcer flags as well - these flags
had no additional meaning beyond "ignore this channel please".
2. It modifies allocation of a channel in two ways:
(a) If a channel technology can be determined from the name, we set it
directly in the allocation routine. This prevents the initial
publication of the message from going out with a NULL channel technology
where possible. This lets Stasis consumers get the right channel
technology on the first publication.
(b) It reorganizes allocation to make use of the 'finalized' property on the
channel. This was already used to know that a channel had completely
finished its construction in the masquerade routine; now we also use it
to know whether or not the setting of certain channel properties is
occurring during or post construction. The various set routines were
modified accordingly as well.
3. The masquerade event is now dead, Jim. It no longer served any purpose
whatsoever - if you perform a call pickup you'll get a Pickup event;
if you perform an attended transfer you will still get those events; if you
steal a channel to put it elsewhere you'll get the corresponding NewExten or
BridgeEnter events.
Review: https://reviewboard.asterisk.org/r/2740
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396392 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Backtraces are allocated outside of the usual memory tracking performed by
MALLOC_DEBUG. This allows them to be used by the memory tracking enabled
by that build option; however, it also means that when backtraces are
disposed of they have to be done so outside of the re-defined free.
This patch undef's free prior to disposing of the allocated backtrace when
a backtrace is appended as a result of 'core show locks'.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396391 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents unreal channel optimization during the prequalification
phase when either channel is involved in DTMF emulation. This prevents
a situation where an emulated digit would be missed because the
emulation was never completed.
Review: https://reviewboard.asterisk.org/r/2747/
(closes issue ASTERISK-22214)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Depending on when a Surrogate channel replaces an existing channel, it is
possible to get a Dial message for the Surrogate channel. When this occurs, no
CDR will exist for the channel as Surrogate channels are ignored. Safely handle
the case when a CDR doesn't exist for a Dial message.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396371 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
The Stasis changes in r395954 had an unanticipated side effect: messages
published directly to an _all topic does not get forwarded to the
corresponding caching topic.
This patch fixes that by changing how caching topics forward messages,
and how the caching pattern forwards are setup.
For the caching pattern, the all_topic is forwarded to the
all_topic_cached. This forwards messages published directly to the
all_topic to all_topic_cached.
In order to avoid duplicate messages on all_topic_cached, caching topics
were changed to no longer forward uncached messages. Subscribers to an
individual caching topic should only expect to receive cache updates,
and subscription change messages. Since individual caching topics are
new, this shouldn't be a problem.
There are a few minor changes to the pre-cache split behavior.
* For topics changed to use the caching pattern, the all_topic_cached
will forward snapshots in addition to cache updates. Since
subscribers by design ignore unexpected messages, this should be
fine.
* Caching topics that don't use the caching pattern no longer forward
non-cache updates. This makes no difference for the current caching
topics.
* mwi_topic_cached, channel_by_name_topic and
presence_state_topic_cached have no subscribers
* device_state_topic_cached's only subscriber only processes cache
udpates
(issue ASTERISK-22243)
Review: https://reviewboard.asterisk.org/r/2738
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396329 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Dial and Queue would previously apply a new set of features whenever
bridging. These options would be based purely on the options supplied
to the dial/queue applications. This patch changes the function those
applications use to bridge calls so that the features will be added
to the set of existing features for each channel rather than having
them override the existing features.
(closes issue ASTERISK-22209)
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/2713/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396245 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Roles are now cleared with each entry into a bridge with addChannel.
If the roles parameter is present, the role specified will be applied
to all channels being added with the addChannel command.
(closes issue ASTERISK-21973)
Reported by: Matt Jordan
https://reviewboard.asterisk.org/r/2691/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396182 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The new res_ari_asterisk.so module presents several config options
from asterisk main. Unfortunately, they aren't exported, so the module
won't load on Linux.
This patch renames the variables, adding the ast_ prefix so they will
be exported.
Review: https://reviewboard.asterisk.org/r/2737
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396166 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AMI message router is owned wholly by manager.c. Previously, each of the
manager_{item} source files had their own message router and they unsubscribed
from each; once they moved over to using a single message router only a single
unsubscribe became necessary.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* BridgeEnter now contains the unique ID of the channel that is to be swapped out, if applicable.
* There is a ParkedCallSwap event that is sent when a parked channel has a new channel take its place.
(closes issue ASTERISK-22193)
reported by Mark Michelson
Review: https://reviewboard.asterisk.org/r/2712
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396107 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This moves ast_str_container_alloc, ast_str_container_add,
ast_str_container_remove, and related private functions into
strings.c/h since they really don't belong in astobj2.c/h.
As a result of this move, utils also had to be updated.
Review: https://reviewboard.asterisk.org/r/2719/
(closes issue ASTERISK-22041)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396105 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 patch does the following:
* It moves the pickup code out of features.c and into pickup.c
* It removes the vast majority of dead code out of features.c. In particular,
this includes the parking code.
(issue ASTERISK-22134)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some regex implementations won't compile an empty string. Assuming that
it's equivalent of a regex that will match anything, use ".?" instead.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396035 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It adds support for externally initiated parking requests. In particular,
chan_skinny has a protocol level message that initiates a call park.
This patch now supports that option, as well as the protocol specific
mechanisms in chan_dahdi/sig_analog and chan_mgcp.
* A parking bridge features virtual table has been added that provides
access to the parking functionality that the Bridging API needs. This
includes requests to park an entire 'call' (with little or no additional
information, thank you chan_skinny), perform a blind transfer to a parking
extension, determine if an extension is a parking extension, as well as the
actual "do the parking" request from the Bridging API.
* Refactoring in chan_mgcp, chan_skinny, and chan_dahdi to make use of the new
functions
* The removal of some - but not all - dead parking code from features.c
This also fixed blind transferring a multi-party bridge to a parking lot (which
was implemented, but had at least one code path where using the parking features
kK might not have worked)
Review: https://reviewboard.asterisk.org/r/2710
(closes issue ASTERISK-22134)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396028 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
In working with res_stasis, I discovered a significant limitation to
the current structure of stasis_caching_topics: you cannot subscribe
to cache updates for a single channel/bridge/endpoint/etc.
To address this, this patch splits the cache away from the
stasis_caching_topic, making it a first class object. The stasis_cache
object is shared amongst individual stasis_caching_topics that are
created per channel/endpoint/etc. These are still forwarded to global
whatever_all_cached topics, so their use from most of the code does
not change.
In making these changes, I noticed that we frequently used a similar
pattern for bridges, endpoints and channels:
single_topic ----------------> all_topic
^
|
single_topic_cached ----+----> all_topic_cached
|
+----> cache
This pattern was extracted as the 'Stasis Caching Pattern', defined in
stasis_caching_pattern.h. This avoids a lot of duplicate code between
the different domain objects.
Since the cache is now disassociated from its upstream caching topics,
this also necessitated a change to how the 'guaranteed' flag worked
for retrieving from a cache. The code for handling the caching
guarantee was extracted into a 'stasis_topic_wait' function, which
works for any stasis_topic.
(closes issue ASTERISK-22002)
Review: https://reviewboard.asterisk.org/r/2672/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395954 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Subversion doesn't do quote processing, so it actually thinks that the
closing quote in 'Revision"' is a part of the keyword.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395686 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Performing a module reload of core components causes specific functions
compiled into the Asterisk binary to be reloaded. The table of said functions
was still pointing to the old features reload mechanism, and not the new one.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This renames all files and API calls from several variants of
Stasis-HTTP to ARI including:
* Stasis-HTTP -> ARI
* STASIS_HTTP -> ARI
* stasis_http -> ari (ast_ari for global symbols, file names as well)
* stasis http -> ARI
Review: https://reviewboard.asterisk.org/r/2706/
(closes issue ASTERISK-22136)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395603 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Most hook callbacks did not need the bridge parameter. The pointer value
could become invalid if the channel is moved to another bridge while it is
executing.
* Fixed some issues in feature_attended_transfer() as a result.
* Reduce the bridge inhibit count in
attended_transfer_properties_shutdown() after it has restored the bridge
channel hooks.
* Removed basic bridge requirement on feature_blind_transfer(). It does
not require the basic bridge like feature_attended_transfer().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed feature limits to not use special members of struct
ast_bridge_features.
* Fixed memory leak in off nominal paths of bridge_builtin_set_limits().
* Fixed off nominal path in ast_bridge_features_limits_construct() freeing
unallocated memory if it was not called by bridge_builtin_set_limits().
* Made bridge_builtin_interval_features.so unloadable.
* Simplified parking's use of its duration interval hook.
* Made BridgeWait S option not depend upon another module being loaded.
(closes issue ASTERISK-22107)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2701/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Changes arguments for BridgeWait from BridgeWait(role, options) to
BridgeWait(bridge_name, role, options). Now multiple holding bridges may
be created and referenced by this application.
(closes issue ASTERISK-21922)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2642/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This removes the previously #if 0'd code. The functionality removed has either
been subsumed by the Bridging API or is no longer applicable.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395400 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
* Convert interval timers to use the ast_waitfor_nandfds() timeout.
* Remove bridge channel action for intervals. Now the main loop handles
running interval hooks.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395340 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Reduced the number of hook containers to just dtmf_hooks,
interval_hooks, and other_hooks. As a result, several functions dealing
with the different hook containers could be combined.
* Extended the generic hook struct for DTMF and interval hooks instead of
using a variant record.
* Merged the special talk detector hook into the other_hooks container.
* Replaced ast_bridge_features_set_talk_detector() with
ast_bridge_talk_detector_hook().
(issue ASTERISK-22107)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395322 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Add an error message so you know when a feature is not available and you
tried to use it. It usually means the module has not been loaded.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395316 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Ensure that the BridgeInfo command provides adequate state information
about channels by publishing the full channel snapshot for
BridgeInfoChannel subevents. This prevents a two-stage lookup since
most consumers will be keying on channel names instead of uniqueids.
(closes issue ASTERISK-22140)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395270 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It pulls out bridge_channel and puts it into its own translation unit
* It adds public and protected headers for bridging_channel. Protected
functions are appropriate only for the Bridging API and sub-classes of a
bridge.
(issue ASTERISK-22130)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395253 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Created a native_dahdi bridging technology for use with the new bridging
API.
The new bridging technology is part of the chan_dahdi channel driver
because it is very specific to that driver. Rather than include the new
code directly into chan_dahdi.c the new bridge technology is in its own
file and linked into chan_dahdi.so. A large part of this change is the
mechanical process of moving declarations around so chan_dahdi.c can be
split up into more files later.
* Changed the bridging core to pass NULL frames into the channel
technologies instead of discarding them. The channel technologies may
need the proding to determine if their configuration is still valid.
(closes issue ASTERISK-21886)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2681/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395154 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This greatly modifies the operation of DTMF attended transfers so that
the full range of options from features.conf applies.
In addition, a new option has been added that allows for a transferer
to switch between bridges during a transfer before completing the
transfer.
(closes issue ASTERISK-21543)
reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2654
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395151 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In previous versions of Asterisk, the zombies roamed freely,
unchecked and uncontrolled. They ravaged Asterisk systems with
their biting and their nashing and their pointy teeth.
Sometimes, you couldn't even hang them up.
Now, zombies are rare. They still *technically* exist in certain
places, but they are controlled. Kind of like a zombie zoo: you can
see them, but you can't touch them, and they can't touch you.
Bring your kids!
Because zombies are now population controlled with a very short lifespan,
there's no reason to rename the channels to '%s<ZOMBIE>'. The channels
are guaranteed to die off quickly; the rename really is just confusing
at this point.
This patch finally removes the renaming. On the plus side: this made
my life easier in CDRs during call pickup and attended transfers to
an Asterisk application. It will make other folks lives easier as well!
Review: https://reviewboard.astierks.org/r/2690/
(closes issue ASTERISK-21699)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The stasis_cache_update messages are somewhat cumbersome to handle
with the stasis_message_router. Since all updates have the same
message type, they are normally handled with the same route.
Since caching itself is a first class component of stasis-core, it
makes sense for the router to handle the cache update messages itself.
This patch adds stasis_message_router_add_cache_update() and
stasis_message_router_remove_cache_update() to handle the routing of
stasis_cache_update messages.
This patch also corrects an issue with manager_{bridging,channels}.c,
where events might be reordered. The reordering occurs because the
components use different message routers, which they needed because
they both needed to route cache update messages. They now both use
manager's router, and add cache routes for just the cache updates they
are interested in.
(closes issue ASTERISK-22038)
Review: https://reviewboard.asterisk.org/r/2677/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395118 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch modifies parsing of cookies in Asterisk's http server by doing an
explicit comparison of the "Cookie" header instead of looking at the first
6 characters to determine if the header is a cookie header. This avoids
parsing "Cookie2" headers and overwriting the previously parsed "Cookie"
header.
Note that we probably should be appending the cookies in each "Cookie"
header to the parsed results; however, while clients can send multiple
cookie headers they never really do. While this patch doesn't improve
Asterisk's behavior in that regard, it shouldn't make it any worse either.
Note that the solution in this patch was pointed out on the issue by the
issue reporter, Stuart Henderson.
(closes issue ASTERISK-21789)
Reported by: Stuart Henderson
Tested by: mjordan, Stuart Henderson
........
Merged revisions 394899 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 394900 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394901 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch modifies manager to allow the allowmultiplelogin setting to be set
on an account by account basis. When set in the general context, it will act
as the default for the defined accounts. Setting it in the account will
override the general setting.
(closes issue ASTERISK-21324)
Reported by: vldmr
patches:
asterisk-manager-per-user-allowmultiplelogin.patch uploaded by vldmr (License 6487)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394881 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a new CEL event type, AST_CEL_LOCAL_OPTIMIZE, to represent
local channel optimizations. Local channel optimizations were one of
several things conveyed by the now defunct BRIDGE_UPDATE event type.
This also adds a unit test to test generation of this new CEL event.
Review: https://reviewboard.asterisk.org/r/2676/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds CEL support for blind and attended transfers and call pickup.
During the course of adding this functionality I noticed that
CONF_ENTER, CONF_EXIT, and BRIDGE_TO_CONF events are particularly
useless without a bridge identifier, so I added that as well.
This adds tests for blind transfers, several types of attended
transfers, and call pickup.
The extra field in CEL records now consists of a JSON blob whose fields
are defined on a per-event basis.
Review: https://reviewboard.asterisk.org/r/2658/
(closes issue ASTERISK-21565)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made ast_audiohook_detach_list() and ast_audiohook_write_list_empty()
NULL tolerant.
* Made ast_audiohook_detach_list() return void since it is a destructor.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394836 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds a new channel driver for creating channels for specific purposes
in bridges, primarily to act as either recorders or announcers. Adds
ARI commands for playing announcements to ever participant in a bridge
as well as for recording a bridge. This patch also includes some
documentation/reponse fixes to related ARI models such as playback
controls.
(closes issue ASTERISK-21592)
Reported by: Matt Jordan
(closes issue ASTERISK-21593)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2670/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds new flags to the channel tech properties that flag it as
different types of implementation detail used exclusively to provide a
feature. Examples of channels that would have these flags include the
announcement and recording channels used by confbridge which are the
only two marked as such by this patch.
Review: https://reviewboard.asterisk.org/r/2633/
(closes issue ASTERISK-21873)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394808 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds more entertainment options to holding bridges and the
bridge_wait application. Also, holding bridges will now use music on
hold as the default entertainment option instead of none. The
parameters for app_bridgewait have changed to (role, options) from
the previous (options) and the options themselves have changed as
well (entertainment options are now contained in an enumerator, role
specification is handled by the role parameter, etc)
(closes issue ASTERISK-21923)
Reported by: Matthew Jordan
Review: https://reviewboard.asterisk.org/r/2679/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does two things:
1. It moves the debug statement that shows the HTTP sub-protocols being
compared after the string length calculation such that it shows the correct
string length in the output
2. It adds some additional debug that displays when it matches on a
sub-protocol and when it fails
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The recent changes to update stasis_cache_topics directly from the
publisher thread uncovered a race condition, which was causing asserts
in the /stasis/core tests.
If the caching topic's subscription is the last reference to the
caching topic, it will destroy the caching topic after the final
message has been processed. When dispatching to a different thread,
this usually gave the unsubscribe enough time to finish before
destruction happened. Now, however, it consistently destroys before
unsubscription is complete.
This patch adds an extra reference to the caching topic, to hold it
for the duration of the unsubscription.
This patch also removes an extra unref that was happening when the
final message was received by the caching topic. It was put there
because of an extra ref that was put into the caching topic's
constructor. Both have been removed, which makes the destructor a bit
less confusing.
Review: https://reviewboard.asterisk.org/r/2675/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394686 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since ast_hangup() is effectively a channel destructor, it should be a
void function.
* Make the few silly callers checking the return value no longer do so.
Only the CDR and CEL unit tests checked the return value.
* Make all callers take advantage of the NULL safe change and remove the
NULL check before the call.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a channel is hungup, both an APP_END event and a HANGUP event can be
fired. To ensure that HANGUP events occur after APP_END events, the method
callbacks for the APP_END event should be processed prior to the callbacks
for the HANGUP event.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394530 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch attempts to fix some possible race conditions in shutdown of the
CDR engine. It:
* Adds a cleanup handler to only unsubscribe and join on stasis messages during
graceful shutdown. The cleanup handler should execute before the regular atexit
handler, as we want to unsubscribe for any further messages before dispatching
the CDRs.
* The CDRs are now locked when we dispatch them on shutdown.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394469 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ill conceived chan_agent is no more. It is now replaced by
app_agent_pool.
Agents login using the AgentLogin() application as before. The
AgentLogin() application no longer does any authentication.
Authentication is now the responsibility of the dialplan. (Besides, the
authentication done by chan_agent did not match what the voice prompts
asked for.)
Sample extensions.conf
[login]
; Sample agent 1001 login
; Set COLP for in between calls so the agent does not see the last caller COLP.
exten => 1001,1,Set(CONNECTEDLINE(all)="Agent Waiting" <1001>)
; Give the agent DTMF transfer and disconnect features when connected to a caller.
same => n,Set(CHANNEL(dtmf-features)=TX)
same => n,AgentLogin(1001)
same => n,NoOp(AGENT_STATUS is ${AGENT_STATUS})
same => n,Hangup()
[caller]
; Sample caller direct connect to agent 1001
exten => 800,1,AgentRequest(1001)
same => n,NoOp(AGENT_STATUS is ${AGENT_STATUS})
same => n,Hangup()
; Sample caller going through a Queue to agent 1001
exten => 900,1,Queue(agent_q)
same => n,Hangup()
Sample queues.conf
[agent_q]
member => Local/800@caller,,SuperAgent,Agent:1001
Under the hood operation overview:
1) Logged in agents wait for callers in an agents holding bridge.
2) Caller requests an agent using AgentRequest()
3) A basic bridge is created, the agent is notified, and caller joins the
basic bridge to wait for the agent.
4) The agent is either automatically connected to the caller or must ack
the call to connect.
5) The agent is moved from the agents holding bridge to the basic bridge.
6) The agent and caller talk.
7) The connection is ended by either party.
8) The agent goes back to the agents holding bridge.
To avoid some locking issues with the agent holding bridge, I needed to
make some changes to the after bridge callback support. The after bridge
callback is now a list of requested callbacks with the last to be added
the only active callback. The after bridge callback for failed callbacks
will always happen in the channel thread when the channel leaves the
bridging system or is destroyed.
(closes issue ASTERISK-21554)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2657/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Peter J Philipp pointed out that there are two checks that ensure that len is
not less than 0. If len is less than 0, the function returns. Having both of
them is clearly redundant.
This removes the second and attempts to clarify (slightly) the error condition.
(closes issue ASTERISK-21772)
Reported by: Peter J Philipp
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394305 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It simplifies the Dial handling in CDRs. As a rule, the caller in a dial
relationship is always the Party A. There was some logic present in the
handling of the dial message that could, conceivably, pick the caller
as Party A for the beginning of the dial and the peer as Party A for the
end of the dial. This shouldn't have happened if the code in the bridging
framework was doing its job; however, that was broken and it led to the
FRACK. As it is, this code was overly ocmplex and not needed: the caller,
if present, should always be Party A. Period.
* It properly checks to see if a channel will continue on in the dialplan.
ast_check_hangup - much like cake at the end - is a lie. It will tell
you that you are hungup when you are not. Do not believe it.
I would make this function tell the truth, but I'm nervous that we've been
depending on it sitting on its throne of lies for far too long, and it would
probably break lots of things. So I'm just checking the "internal" soft
hangup flags, like everyone else.
(closes issue ASTERISK-22060)
Reported by: Mark Michelson
(issue ASTERISK-21831)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It adds a virtual table of callbacks to core_unreal. These callbacks can be
supplied by concrete implementations of "unreal" channel drivers, which lets
the unreal channel driver call specific functionality when it performs some
action. Currently, this is done to notify implementations when an
optimization operation has begun, and when an optimization operation has
succeeded.
* It adds Stasis-Core messages for Local channel bridging and Local channel
optimization. Local channel optimization is now two events: a Begin and an
End. Some consumers of Stasis-Core may want to know when an operation is
beginning so that they can 'prepare' their information; others will be more
concerned about when the operation has completed, so that they can 'fix up'
information. Stasis-Core allows for both, as does AMI.
Review: https://reviewboard.asterisk.org/r/2552
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393801 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch reorders certain actions that may raise Stasis messages in the
channel destructor such that they occur before the Stasis cache is cleared.
Once the Stasis cache is cleared, its rather a bad idea to be trying to
publish information about a channel.
(closes issue ASTERISK-22001)
Reported by: Jonathan Rose
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It adds a new soft hangup flag AST_SOFTHANGUP_HANGUP_EXEC that is set when a
channel is executing dialplan hangup logic, i.e., the 'h' extension or a
hangup handler. Stasis messages now also convey the soft hangup flag so
consumers of the messages can know when a channel is executing said
hangup logic.
* It adds a new channel flag, AST_FLAG_DEAD, which is set when a channel is
well and truly dead. Not just a zombie, but dead, Jim. Manager, CEL, CDRs,
and other consumers of Stasis have been updated to look for this flag to
know when the channel should by lying six feet under.
* The CDR engine has been updated to better handle a channel entering and
leaving a bridge. Previously, a new CDR was automatically created when a
channel left a bridge and put into the 'Pending' state; however, this
way of handling CDRs made it difficult for the 'endbeforehexten' logic to
work correctly - there was always a new CDR waiting in the hangup logic
and, even if 'ended', wouldn't be the CDR people wanted to inspect in the
hangup routine. This patch completely removes the Pending state and instead
defers creation of the new CDR until it gets a new message that requires
a new CDR.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It merges Jaco Kroon's patch from ASTERISK-20754, which provides channel
information in the RTCP events. Because Stasis provides a cache, Jaco's
patch was modified to pass the channel uniqueid to the RTP layer as
opposed to a pointer to the channel. This has the following benefits:
(1) It keeps the RTP engine 'clean' of references back to channels
(2) It prevents circular dependencies and other potential ref counting issues
* The RTP engine now allows any RTP implementation to raise RTCP messages.
Potentially, other implementations (such as res_rtp_multicast) could also
raise RTCP information. The engine provides structs to represent RTCP headers
and RTCP SR/RR reports.
* Some general refactoring in res_rtp_asterisk was done to try and tame the
RTCP code. It isn't perfect - that's *way* beyond the scope of this work -
but it does feel marginally better.
* A few random bugs were fixed in the RTCP statistics. (Example: performing an
assignment of a = a is probably not correct)
* We now raise RTCP events for each SR/RR sent/received. Previously we wouldn't
raise an event when we sent a RR report.
Note that this work will be of use to others who want to monitor call quality
or build modules that report call quality statistics. Since the events are now
moving across the Stasis message bus, this is far easier to accomplish. It is
also a first step (though by no means the last step) towards getting Olle's
pinefrog work incorporated.
Again: note that the patch by Jaco Kroon was modified slightly for this work;
however, he did all of the hard work in finding the right places to set the
channel in the RTP engine across the channel drivers. Much thanks goes to Jaco
for his hard work here.
Review: https://reviewboard.asterisk.org/r/2603/
(closes issue ASTERISK-20574)
Reported by: Jaco Kroon
patches:
asterisk-rtcp-channel.patch uploaded by jkroon (License 5671)
(closes issue ASTERISK-21471)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Legacy channel drivers often include the ability to set a default parking lot
on an endpoint basis; when channels are created for that endpoint, they inherit
the parkinglot option. Parking used to use this option more frequently; while
it is still supported, other options (such as using channel variables or
creation of a custom parkinglot) are supported. More importantly, conveying the
parkinglot information through a channel snapshot isn't terribly useful - it
is rarely (if ever) changed on a channel and some consumers of channel
snapshots, such as ARI, will never use the information.
(closes issue ASTERISK-21968)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393716 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This process also involved a large amount of rework regarding how to redial
the Parker when a channel leaves a parking lot due to timeout. An attended
transfer channel variable has been added to attended transfers to extensions
that will eventually park (but haven't at the time of transfer) as well.
This resolves one of the two BUGBUG comments remaining in res_parking.
(issues ASTERISK-21877)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2638/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393704 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes a few minor bugs and one major one: the CDR by bridge
container was less than helpful. The mechanism previously used to try
and find all of the CDRs in a particular bridge ended up missing CDRs,
resulting in incorrect records.
When looking up CDRs in a bridge, we now just bite the bullet and do
a selection across all existing CDRs.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393599 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While a Stasis configuration file is nice, it shouldn't be mandatory.
We can carry on with default values.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393589 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, the order of procedures on a bridge push was
* Add new bridge channel to bridge's array.
* Pull the swap channel out of the bridge
* Publish a bridge enter event.
The problem is that when the swap channel was pulled from the bridge,
a bridge leave event would be published. The bridge snapshot
published during the bridge leave showed the new channel that had
been added to the bridge, but there had been no bridge enter event
for that channel.
The fix provided here was to change the order a bit
* Add new bridge channel to bridge's array.
* Publish bridge enter event.
* Pull the swap channel out of the bridge.
This makes it so that the bridge snapshots during the stasis
events are accurate.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393586 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the first step in adding recording support to the
Asterisk REST Interface.
Recordings are stored in /var/spool/recording. Since recordings may be
destructive (overwriting existing files), the API rejects attempts to
escape the recording directory (avoiding issues if someone attempts to
record to ../../lib/sounds/greeting, for example).
(closes issue ASTERISK-21594)
(closes issue ASTERISK-21581)
Review: https://reviewboard.asterisk.org/r/2612/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393550 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The appropriate settings for the Stasis threadpool is very system
specific, depending upon both workload and system configuration.
This patch adds a stasis.conf file which can be used to configure the
key attributes of the threadpool for the Stasis message bus.
(closes issue ASTERISK-21280)
Review: https://reviewboard.asterisk.org/r/2651/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393542 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds authentication support to ARI.
Two authentication methods are supported. The first is HTTP Basic
authentication, as specified in RFC 2617[1]. The second is by simply
passing the username and password as an ?api_key query parameter
(which allows swagger-ui[2] to authenticate more easily).
ARI usernames and passwords are configured in the ari.conf file
(formerly known as stasis_http.conf). The user may be set to
`read_only`, which will prohibit the user from issuing POST, DELETE,
etc. Also, the user's password may be specified in either plaintext,
or encrypted using the crypt() function.
Several other notes about the patch.
* A few command line commands for seeing ARI config and status were
also added.
* The configuration parsing grew big enough that I extracted it to
its own file.
[1]: http://www.ietf.org/rfc/rfc2617.txt [2]:
https://github.com/wordnik/swagger-ui
(closes issue ASTERISK-21277)
Review: https://reviewboard.asterisk.org/r/2649/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393530 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Refactored the AMI events in AOC onto Stasis-Core. The ast_aoc_manager_event
function now publishes a channel snapshot, along with a JSON blob describing
the advice of charge. A "to_ami" handler has also been added that converts
the channel snapshot and AOC event data back into the appropriate data structure
for use with AMI.
(closes issue ASTERISK-21472)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2643/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393449 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds several unit tests for CEL functionality and provides the
requisite framework for creating additional unit tests.
This also cleans up some reference leaks that were occurring in
Stasis-Core message callback code.
Review: https://reviewboard.asterisk.org/r/2646/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The originate APIs allow callers to provide a pointer to a channel that will
point to the originated channel if the function call succeeds. This is used by AMI
to provide channel information when the originate is performed synchronously.
Unfortunately, if the originate fails in certain ways, the outbound channel is
already disposed of during the dialing itself. This results in the channel being
improperly dereferenced by the internal originate function in pbx.c.
This patch ref bumps the channel to prevent this from occurring. Callers must now
unlock and unref the channel (which is more in line with general channel management
guidelines anyway).
This only affects manager, as it is the only consumer of this API function that
actually passes in a channel pointer.
Review: https://reviewboard.asterisk.org/r/2617/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393361 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In addition to porting those features, they now enjoy greater feature parity
with one another. Specifically, AutoMixMon now has a start and stop
message that can be specified with TOUCH_MIXMONITOR_MESSAGE_START and
TOUCH_MIXMONITOR_MESSAGE_STOP.
(closes issue ASTERISK-21553)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2620/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393309 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Originated channels are a bit odd - they are technically a dialed channel (thus
the party B or peer) but, since there is no caller, they are treated as the
party A. When entering into a bridge that already contains participants, the CDR
engine - if the CDR record is in the Dial state - attempts to match the person
entering the bridge with an existing participant. The idea is that if you dialed
someone and the person you dialed is already in the bridge, you don't need a new
CDR record, the existing CDR record describes the relationship.
Unfortunately, for an originated channel, there is no Party B. If no one was in
the bridge this didn't cause any issues; however, if participants were in the
bridge the CDR engine would attempt to match a non-existant Party B on the
channel's CDR record and explode.
This patch fixes that, and a unit test has been added to cover this case.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393164 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Parking typically occurs when a channel is transferred to a parking extension.
When this occurs, the channel never actually hits the dialplan if the extension
it was transferred to was a "parking extension", that is, the extension in
the first priority calls the Park application. Instead, the channel is
immediately sent into the holding bridge acting as the parking bridge.
This is problematic.
Because we never go out to the dialplan, the CDRs won't transition properly
and the application field will not be set to "Park". CDRs typically swallow
holding bridges, so the CDR itself won't even be generated.
This patch handles this by pulling out the holding bridge handling into its
own CDR state. CDRs now have an explicit parking state that accounts for this
specific subclass of the holding bridge. In addition, we handle the parking
stasis message to set application specific data on the CDR such that the
last known application for the CDR properly reflects "Park".
This is a bit sad since we're working around the odd internal implementation
of parking that exists in Asterisk (and that we had to maintain in order to
continue to meet some odd use cases of parking), but at least the code to
handle that is where it belongs: in CDRs as opposed to sprinkled liberally
throughout the codebase.
This patch also properly clears the OUTBOUND channel flag from a channel when
it leaves a bridge, and tweaks up dialing handling to properly compare the
correct CDR with the channel calling/being dialed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393130 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add config framework OPT_CHAR_ARRAY_T and OPT_STRINGFIELD_T non-empty
requirement option. There are cases were you don't want a config option
string to be empty. To require the option string to be non-empty, just
set the aco_option_register() flags parameter to non-zero.
* Updated some config framework enum aco_option_type comments.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393034 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix locking problems. ast_bridge_move() locks two bridges. To do that,
deadlock avoidance must be done. Called bridge_move_locked() instead.
* Fix inconsistency in the bridge dissolve check callers. The original
caller has already removed the channel from the bridge. The new caller
has not removed the channel from the bridge. Reverted
bridge_dissolve_check() and added bridge_dissolve_check_stolen() to be
used by the new caller on the original bridge after the channel is moved
to the new bridge.
* Fix memory leak of features if the added channel was already in a
bridge.
* Fix incorrect call to ast_bridge_impart().
* Renamed bridge_chan to yanked_chan.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392953 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change removes AST_CEL_BRIDGE_UPDATE since it should no longer be
used because masquerade situations are now accounted for in other ways.
This also refactors usage of AST_CEL_FORWARD to be produced by a Dial
message which has been extended with a "forward" field.
(closes issue ASTERISK-21566)
Review: https://reviewboard.asterisk.org/r/2635/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes the following memory leaks:
* http.c: The structure containing the addresses to bind to was not being
deallocated when no longer used
* named_acl.c: The global configuration information was not disposed of
* config_options.c: An invalid read was occurring for certain option types.
* res_calendar.c: The loaded calendars on module unload were not being
properly disposed of.
* chan_motif.c: The format capabilities needed to be disposed of on module
unload. In addition, this now specifies the default options for the
maxpayloads and maxicecandidates in such a way that it doesn't cause the
invalid read in config_options.c to occur.
(issue ASTERISK-21906)
Reported by: John Hardin
patches:
http.patch uploaded by jhardin (license 6512)
named_acl.patch uploaded by jhardin (license 6512)
config_options.patch uploaded by jhardin (license 6512)
res_calendar.patch uploaded by jhardin (license 6512)
chan_motif.patch uploaded by jhardin (license 6512)
........
Merged revisions 392810 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392812 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses the following memory/ref counting leaks:
* main/devicestate.c - unsubscribe and join our devicestate message
subscription
* main/cel.c - clean up the datastore and config objects on exist
* main/parking.c - cleanup memory leak of retriever snapshot on message
payload destruction
* res/parking/parking_bridge.c - cleanup memory leak of retrieve snapshot
on message payload destruction
* main/presencestate.c - unsubscribe and join the caching topic on exit
* manager.c - properly unregister the manager action "BlindTransfer"
* sorcery.c - shutdown the threadpool on exit and dispose of any wizards
(issue ASTERISK-21906)
Reported by: John Hardin
patches:
cel.patch uploaded by jhardin (license #6512)
devicestate.patch uploaded by jhardin (license #6512)
manager.patch uploaded by jardin (license #6512)
presencestate.patch uploaded by jhardin (license #6512)
retriever-channel-snapshot.patch uploaded by jhardin (license #6512)
sorcery.patch uploaded by jhardin (license #6512)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392797 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds support for stasis/sounds and stasis/sounds/{ID} queries via
the Asterisk RESTful Interface (ARI, formerly Stasis-HTTP).
The following changes have been made to accomplish this:
* A modular indexer was created for local media.
* A new function to get an ast_format associated with a file extension
was added.
* Modifications were made to the built-in HTTP server so that URI
decoding could be deferred to the URI handler when necessary.
* The Stasis-HTTP sounds JSON documentation was modified to handle
cases where multiple languages are installed in different formats.
* Register and Unregister events for formats were added to the system
topic.
(closes issue ASTERISK-21584)
(closes issue ASTERISK-21585)
Review: https://reviewboard.asterisk.org/r/2507/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392700 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was caused by forwarding all endpoint messages to manager which includes
channel messages that are related to the endpoint. This change causes only
the PeerStatus messages to be forwarded to manager thus eliminating the
duplicate channel messages.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392627 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Sorcery specific object information is now opaque and allocated with the object.
This means that modules do not need to be recompiled if the sorcery specific part
is changed. It also means that sorcery can store additional information on objects
and ensure it is freed or the reference count decreased when the object goes away.
To facilitate the above a generic sorcery allocator function has been added which
also ensures that allocated objects do not have a lock.
Extended fields have been added thanks to all of the above which allows specific fields
to be marked as extended, and thus simply stored as-is within the object. Type safety
is *NOT* enforced on these fields. A consumer of them has to query and ultimately perform
their own safety check. What does this mean? Extra modules can extend already defined
structures without having to modify them.
Tests have also been included to verify extended field functionality.
Review: https://reviewboard.asterisk.org/r/2585/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392586 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1. Security events
2. Websocket support
3. Diversion header + redirecting support
4. An anonymous endpoint identifier
5. Inbound extension state subscription support
6. PIDF notify generation
7. One touch recording support (special thanks Sean Bright!)
8. Blind and attended transfer support
9. Automatic inbound registration expiration
10. SRTP support
11. Media offer control dialplan function
12. Connected line support
13. SendText() support
14. Qualify support
15. Inband DTMF detection
16. Call and pickup groups
17. Messaging support
Thanks everyone!
Side note: I'm reminded of the song "How Far We've Come" by Matchbox Twenty.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Extract a useful routine from the softmix bridge technology for other
technologies. Make other technologies use it if they can.
* Made native and 1-1 bridges write to all parties if the bridge channel
writing the frame into the bridge is NULL. Softmix will also do the same
for frame types that make sense.
* Tweak the bridge write routine return value meaning and adjust the
bridge technologies to match.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392514 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The bridge frame queue functions need to return an error status if the
frame failed to be queued because of an error condition. The main calls
that needed to return the status are:
ast_bridge_channel_queue_action_data() and
ast_bridge_channel_write_action_data(). The other return changes are
ripple effects.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a threadpool is set to autoincrement its threadcount, an issue
may arise when multiple tasks are queued at once into the threadpool. Since
threads start active, each new task would result in autoincrementing the
thread count. So if all threads were active, and a thread's autoincrement
value were 5, then 3 new tasks would result in 15 threads being created even
though the initial autoincrement was sufficient to handle the number of tasks.
This change introduces three behavior changes:
1) New threads in the threadpool start idle instead of active.
2) When a threadpool autoincrements, one thread is activated after the growth.
3) When a threadpool's size is incremented manually, all added threads are activated.
For a more detailed explanation about the changes, please see the Review Board link
at the bottom of this commit.
Review: https://reviewboard.asterisk.org/r/2629
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392318 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For about forever, our build flags for OS X have been slightly off, but
good enough to build and run. Apparently they aren't good enough any more.
Previously, we would compile with macosx-version-min unset and link with
it set. This combination, using GCC 4.8, on Mountain Lion, would create a
bad executable ("Illegal Instruction: 4", or something like that)
This patch consistently sets macosx-version-min for both compiling and
linking, which makes everything happy enough to build and run.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392279 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This finishes moving all CEL linkedid tracking entirely within cel.c
since that is now possible with channel snapshots.
This also removes another CEL linkedid manipulation function from cel.h
that has already been internalized and is neither called nor available
to link against.
Review: https://reviewboard.asterisk.org/r/2632/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392241 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