| Age | Commit message (Collapse) | Author |
|---|
|
........
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
|
|
The Dial, Queue, and FollowMe applications need to inhibit the bridging
initial connected line exchange in order to support the 'I' option.
* Replaced the pass_reference flag on ast_bridge_join() with a flags
parameter to pass other flags defined by enum ast_bridge_join_flags.
* Replaced the independent flag on ast_bridge_impart() with a flags
parameter to pass other flags defined by enum ast_bridge_impart_flags.
* Since the Dial, Queue, and FollowMe applications are now the only
callers of ast_bridge_call() and ast_bridge_call_with_flags(), changed the
calling contract to require the initial COLP exchange to already have been
done by the caller.
* Made all callers of ast_bridge_impart() check the return value. It is
important. As a precaution, I also made the compiler complain now if it
is not checked.
* Did some cleanup in parking_tests.c as a result of checking the
ast_bridge_impart() return value.
An independent, but associated change is:
* Reduce stack usage in ast_indicate_data() and add a dropping redundant
connected line verbose message.
(closes issue ASTERISK-22072)
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/2845/
........
Merged revisions 399136 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
DTMF start/end and hold/unhold events have state because a DTMF begin
event and hold event must be ended by something.
The following cases need to be handled when a channel is moved around in
the system.
* When a channel leaves a bridge it may owe a DTMF end event to the
bridge.
* When a channel leaves a bridge it may owe an UNHOLD event to the bridge.
(This case is explicitly ignored because things like transfers need
explicit control over this.)
* When a channel leaves the bridging system it may need to simulate a DTMF
end event to the channel.
* When a channel leaves the bridging system it may need to simulate an
UNHOLD event to the channel.
The patch also fixes the following:
* Fixes playing a file and restarting MOH using the latest MOH class used.
(closes issue ASTERISK-22043)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2791/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397577 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch adds pass through support for Opus and VP8. That includes:
* Format attribute negotiation for Opus. Note that unlike some other codecs,
the draft RFC specifies having spaces delimiting the attributes in addition
to ';', so you have "attra=X; attrb=Y". This broke the attribute parsing in
chan_sip, so a small tweak was also included in this patch for that.
* A format attribute negotiation module for Opus, res_format_attr_opus
* Fast picture update for VP8. Since VP8 uses a different RTCP packet number
than FIR, this really is specific to VP8 at this time.
Note that the format attribute negotiation in res_pjsip_sdp_rtp was written
by mjordan. The rest of this patch was written completely by Lorenzo Miniero.
Review: https://reviewboard.asterisk.org/r/2723/
(closes issue ASTERISK-21981)
Reported by: Tzafrir Cohen
patches:
asterisk_opus+vp8_passthrough_20130718.patch uploaded by lminiero (License 6518)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397526 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397494 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This adds a new dialplan application, SayAlphaCase, that performs much
the same function as SayAlpha except that it takes additional options
which allow the user to specify whether the case of each letter should
be announced for uppercase, lowercase, or all letters. Similar
functionality has been added to the SAY ALPHA AGI command via an
optional parameter.
Original Patch by: Kevin Scott Adams
Reported by: Kevin Scott Adams
Review: https://reviewboard.asterisk.org/r/2725/
(closes issue ASTERISK-20782)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397493 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396713 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
|
|
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 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
|
|
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 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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395255 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
|
|
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
|
|
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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394825 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Also convert res_mutestream to use the core feature behind this.
(closes issue ASTERISK-21618)
Review: https://reviewboard.asterisk.org/r/2652/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394715 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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
join a 2 party bridge.
(closes issue ASTERISK-21829)
Review: https://reviewboard.asterisk.org/r/2636/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394249 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
when retrieving information.
(closes issue ASTERISK-21883)
Review: https://reviewboard.asterisk.org/r/2645/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393831 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 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 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
|
|
inconsistency.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392073 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
|
|
This uses the channel state change events from Stasis-Core to determine
when channel-related CEL events should be raised. Those refactored in
this patch are:
* AST_CEL_CHANNEL_START
* AST_CEL_ANSWER
* AST_CEL_APP_START
* AST_CEL_APP_END
* AST_CEL_HANGUP
* AST_CEL_CHANNEL_END
Retirement of Linked IDs is also refactored.
CEL configuration has been refactored to use the config framework.
Note: Some HANGUP events are not generated correctly because the bridge
layer does not propagate hangupcause/hangupsource information yet.
Review: https://reviewboard.asterisk.org/r/2544/
(closes issue ASTERISK-21563)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Stasis cache clear message payloads now consist of a stasis_message
representative of the message to be cleared from the cache. This allows
multiple parallel caches to coexist and be cleared properly by the same
cache clear message even when keyed on different fields.
This change fixes a bug where multiple cache clears could be posted for
channels. The cache clear is now produced in the destructor instead of
ast_hangup.
Additionally, dummy channels are no longer capable of producing channel
snapshots.
Review: https://reviewboard.asterisk.org/r/2596
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
transfer functions.
(closes issue ASTERISK-21523)
Reported by: Matt Jordan
(closes issue ASTERISK-21524)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2600/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390804 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
state producer can use
an up to date snapshot.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390473 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* Added some more BUGBUG notes.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390291 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* DTMF attended and blind transfers have hold/unhold behavior restored.
* External attended and blind transfers unhold the transfered party when
the transfer is initiated.
* Made prohibit blind transferring a bridge marked as masquerade only.
(ConfBridge bridges)
* Made running an application or playing a file inside a bridge post the
hold/unhold messages if MOH is requested.
Review: https://reviewboard.asterisk.org/r/2574/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390289 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch addresses issues during immediate shutdowns, where modules
are not unloaded, but Asterisk atexit handlers are run.
In the typical case, this usually isn't a big deal. But the
introduction of the Stasis message bus makes it much more likely for
asynchronous activity to be happening off in some thread during
shutdown.
During an immediate shutdown, Asterisk skips unloading modules. But
while it is processing the atexit handlers, there is a window of time
where some of the core message types have been cleaned up, but the
message bus is still running. Specifically, it's still running
module subscriptions that might be using the core message types. If a
message is received by that subscription in that window, it will
attempt to use a message type that has been cleaned up.
To solve this problem, this patch introduces ast_register_cleanup().
This function operates identically to ast_register_atexit(), except
that cleanup calls are not invoked on an immediate shutdown. All of
the core message type and topic cleanup was moved from atexit handlers
to cleanup handlers.
This ensures that core type and topic cleanup only happens if the
modules that used them are first unloaded.
This patch also changes the ast_assert() when accessing a cleaned up
or uninitialized message type to an error log message. Message type
functions are actually NULL safe across the board, so the assert was a
bit heavy handed. Especially for anyone with DO_CRASH enabled.
Review: https://reviewboard.asterisk.org/r/2562/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390122 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Check the returned bridged pointer for NULL to avoid a crash. It looks
like chan_agent is returning a NULL pointer when it probably should be
returning a pointer to the channel the Agent channel is pretending to be.
(closes issue ASTERISK-21793)
Reported by: Rodrigo P. Telles
Patches:
jira_asterisk_21793_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: Rodrigo P. Telles
........
Merged revisions 390044 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 390047 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
masquerades.
The attended transfer API call can complete the attended transfer in a number of ways
depending on the current bridged states of the channels involved.
The hiding of masquerades is done in some bridging-related functions, such as the manager
Bridge action and the Bridge dialplan application. In addition, call pickup was edited
to "move" a channel rather than masquerade it.
Review: https://reviewboard.asterisk.org/r/2511
(closes issue ASTERISK-21334)
Reported by Matt Jordan
(closes issue Asterisk-21336)
Reported by Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389848 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue ASTERISK-21487)
Review: https://reviewboard.asterisk.org/r/2565/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389746 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
|
|
This patch does two things:
* It fixes a bug where the outbound channel's application/data set by the
dialing API/app_dial is not communicated until the channel is hung up.
If that happens, AMI would incorrectly send a NewExten event immediately
after a Hangup. This isn't really AMI's fault, as the dialing APIs never
communicated the 'helpful' app/data on the outbound channel until it was
hungup.
* It makes public sending a stasis message about a change in channel state.
This is useful enough that - for now at least - it should be public. If
operations on a channel go to being more coarse-grained, this function
could be made private again.
Review: https://reviewboard.asterisk.org/r/2548
Note that this problem was found and reported by Matt DiMeo.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When we first introduced the channel blob types, the JSON blobs were
self identifying by a required "type" field in the JSON object
itself. This, as it turns out, was a bad idea.
When we introduced the message router, it was useless for routing based
on the JSON type. And messages had two type fields to check: the
stasis_message_type() of the message itself, plus the type field in the
JSON blob (but only if it was a blob message).
This patch corrects that mistake by removing the required type field
from JSON blobs, and introducing first class stasis_message_type objects
for the actual message type.
Since we now will have a proliferation of message types, I introduced a
few macros to help reduce the amount of boilerplate necessary to set
them up.
Review: https://reviewboard.asterisk.org/r/2509
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387482 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The two party bridging loops were changing the bridge peer pointers
without the channel locks held. Thus when ast_channel_massquerade()
tested and used the pointer there is a small window of opportunity for the
pointers to become NULL even though the masquerade code has the channels
locked.
(closes issue ASTERISK-21356)
Reported by: William luke
Patches:
jira_asterisk_21356_v11.patch (license #5621) patch uploaded by rmudgett
Tested by: William luke
........
Merged revisions 386256 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 386286 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386289 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
refactored to use these events rather than producing the events directly
in channel.c. Finally, the code was added to app_stasis to produce
DTMF events on the WebSocket.
The AMI events are completely backward compatible, including sending
events on transmitted DTMF, and sending DTMF start events.
The Stasis-HTTP events are somewhat simplified. Since DTMF start and
DTMF send events are generally less useful, Stasis-HTTP will only send
events on received DTMF end.
(closes issue ASTERISK-21282)
(closes issue ASTERISK-21359)
Review: https://reviewboard.asterisk.org/r/2439
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385734 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch does the following:
* A new Stasis payload has been defined for multi-channel messages. This
payload can store multiple ast_channel_snapshot objects along with a single
JSON blob. The payload object itself is opaque; the snapshots are stored
in a container keyed by roles. APIs have been provided to query for and
retrieve the snapshots from the payload object.
* The Dial AMI events have been refactored onto Stasis. This includes dial
messages in app_dial, as well as the core dialing framework. The AMI events
have been modified to send out a DialBegin/DialEnd events, as opposed to
the subevent type that was previously used.
* Stasis messages, types, and other objects related to channels have been
placed in their own file, stasis_channels. Unit tests for some of these
objects/messages have also been written.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
correctly.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384261 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
HangupRequest and SoftHangupRequest are now ast_channel_blob Stasis
messages, with the cause code as an optional field in the blob.
NewCallerid now simply watches for changes in the callerid information
in channel snapshots, and creates the AMI event appropriately.
Since the original NewCallerid event honored the channelvars setting
in manager.conf, the channel variables configured there had to become
a part of the channel snapshot. These are now a part of every snapshot
based event, making the configuration description "every time a
channel-oriented event is emitted" less of a lie.
There a a few other changes wrapped up in here as well.
* When ast_channel_topic() is given NULL for a channel, it returns
the ast_channel_topic_all() topic instead of NULL. This can clean
up a lot of NULL checking we're doing currently.
* The fields Cause and Cause-txt were removed from the base channel
information and put only on the Hangup events, since those fields
are meaningless outside of a Hangup event.
* Removed the pipe-delimiter processing of the channelvars field,
since that's been deprecated forever.
(closes issue ASTERISK-21096)
Review: https://reviewboard.asterisk.org/r/2405/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383726 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch started out simply as fixing the bouncing tests introduced
in r382685, but required some other changes to give it a decent
implementation.
To fix the bouncing tests, the UserEvent and Newexten AMI events
needed to be refactored to dispatch via Stasis. Dispatching directly
to AMI resulted in those events sometimes getting ahead of the
associated Newchannel events, which would understandably confuse anyone.
I found that instead of creating a zillion different message types and
structures associated with them, it would be preferable to define a
message type that has a channel snapshot and a blob of structured data
with a small bit of additional information. The JSON object model
provides a very nice way of representing structured data, so I went
with that.
* Move JSON support from res_json.c to main/json.c
* Made libjansson-dev a required dependency
* Added an ast_channel_blob message type, which has a channel
snapshot and JSON blob of data.
* Changed UserEvent and Newexten events so that they are dispatched
via ast_channel_blob messages on the channel's topic.
* Got rid of the ast_channel_varset message; used ast_channel_blob
instead.
* Extracted the manager functions converting Stasis channel events to
AMI events into manager_channel.c.
(issue ASTERISK-21096)
Review: https://reviewboard.asterisk.org/r/2381/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383579 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
