Fixes typos of "transfered" instead of "transferred" in various code. Fixes incorrect gosub param help text for app_queue.
Fixes Asterisk man pages containing unquoted minus signs. Adds note about the "textsupport" option in sip.conf.sample.
(issue ASTERISK-23061)
(issue ASTERISK-23028)
(issue ASTERISK-23046)
(issue ASTERISK-23027)
(closes issue ASTERISK-23061)
(closes issue ASTERISK-23028)
(closes issue ASTERISK-23046)
(closes issue ASTERISK-23027)
Reported by: Eugene, Jeremy Laine, Denis Pantsyrev
Patches:
transferred.patch uploaded by Jeremy Laine (license 6561)
hyphen.patch uploaded by Jeremy Laine (license 6561)
sip.conf.sample.patch uploaded by Eugene (license 6360)
........
Merged revisions 405791 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 405792 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 405829 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Original commit message by mmichelson (asterisk 12 r403311):
"This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such."
The above was initially committed and then reverted at r403398. The problem
was found to be in core_local.c in the publish_local_bridge_message function.
The ast_unreal_lock_all function locks and adds a reference to the returned
channels and while they were being unlocked they were not being unreffed when
no longer needed. Fixed by unreffing the channels.
Also in bridge.c a lock was obtained on "other->chan", but then an attempt was
made to unlock "other" and not the previously locked channel. Fixed by
unlocking "other->chan"
(closes issue ASTERISK-22709)
Reported by: John Bigelow
........
Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds an event for when an originated call is redirected to
another target. This event contains the original channel and the newly
created channel. If a stasis subscription exists on the original originated
channel for a stasis application then a new subscription will also be
created on the stasis application to the redirected channel. This allows
the application to follow the call path completely.
(closes issue ASTERISK-22719)
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/3054/
........
Merged revisions 403808 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403810 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such.
........
Merged revisions 403311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the first agent/member (via CLI "queue show") in a queue is "busy" (dnd,
circuit busy, etc...) and no agents answered then app_queue would crash.
This occurred because while the calling of agent(s) remained valid the channel
on "busy" agent would be set to NULL and then later dereferenced upon a second
"rna" function call. The original intention of the code is to have only valid
"call attempt" objects (channels != NULL) checked while attempting to call
agent(s). It does this by building a "call_next" list of valid "call attempt"
objects. In the case of the "busy" agent subsequent builds of the valid "call
attempt" list would sometimes include (the case mentioned above) an invalid
"call attempt" object.
The fix was to make sure the "call attempt" list was appropriately built on
every iteration. A NULL sanity check was also added at the original offending
spot of the crash just in case another one slipped by somehow.
(closes issue ASTERISK-22644)
Reported by: Marco Signorini
Review: https://reviewboard.asterisk.org/r/2983/
........
Merged revisions 402517 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402518 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The queue_log entry resulting from CLI "queue remove member" when
log_membername_as_agent is enabled is wrong. It always uses the interface
name instead of the member name in the queue_log entry.
* Get the queue member before removing it from the queue so the member
name is available for the queue_log entry.
(closes issue ASTERISK-21826)
Reported by: Oscar Esteve
Patches:
fix_membername.diff (license #6505) patch uploaded by Oscar Esteve
(modified to fix potential ref leak)
........
Merged revisions 401433 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 401434 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The https://reviewboard.asterisk.org/r/2888/ review changes manager to not
subscribe to stasis when it is disabled for performance reasons. When
manager is disabled app_queue and res_agi decline to load and fail to
clean up what they have already allocated.
* Made app_queue and res_agi clean up allocated resources when they
decline to load.
* Made app_queue and res_agi use their own subscriptions to the stasis
topics instead of borrowing manager's message router structure
inappropriately.
(closes issue ASTERISK-22604)
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/2902/
........
Merged revisions 400671 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Commit r62462 added two extra fields for logging "the original position the
caller entered the queue at, and the amount of time the caller was waiting in
the queue." But when r75969 was merged from 1.4 into trunk (r75977), these two
fields disappeared. Those two extra fields were not logged in 1.4 and when the
patch was merged, those fields went away.
Therefore, this is a regression and was caught by the reporter because he was
reading the awesome "Asterisk: The Definitive Guide" book.
(closes issue ASTERISK-22197)
Reported by: Dalius M.
Tested by: Dalius M.
Patches:
asterisk-22197-q-log-exitwithkey.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2901/
........
Merged revisions 400622 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 400623 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 400624 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400625 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line
Minor performance bump by not allocate manager variable struct if we don't need it
........
r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines
Stasis performance improvements
This patch addresses several performance problems that were found in
the initial performance testing of Asterisk 12.
The Stasis dispatch object was allocated as an AO2 object, even though
it has a very confined lifecycle. This was replaced with a straight
ast_malloc().
The Stasis message router was spending an inordinate amount of time
searching hash tables. In this case, most of our routers had 6 or
fewer routes in them to begin with. This was replaced with an array
that's searched linearly for the route.
We more heavily rely on AO2 objects in Asterisk 12, and the memset()
in ao2_ref() actually became noticeable on the profile. This was
#ifdef'ed to only run when AO2_DEBUG was enabled.
After being misled by an erroneous comment in taskprocessor.c during
profiling, the wrong comment was removed.
Review: https://reviewboard.asterisk.org/r/2873/
........
r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines
Taskprocessor optimization; switch Stasis to use taskprocessors
This patch optimizes taskprocessor to use a semaphore for signaling,
which the OS can do a better job at managing contention and waiting
that we can with a mutex and condition.
The taskprocessor execution was also slightly optimized to reduce the
number of locks taken.
The only observable difference in the taskprocessor implementation is
that when the final reference to the taskprocessor goes away, it will
execute all tasks to completion instead of discarding the unexecuted
tasks.
For systems where unnamed semaphores are not supported, a really
simple semaphore implementation is provided. (Which gives identical
performance as the original taskprocessor implementation).
The way we ended up implementing Stasis caused the threadpool to be a
burden instead of a boost to performance. This was switched to just
use taskprocessors directly for subscriptions.
Review: https://reviewboard.asterisk.org/r/2881/
........
r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines
Optimize how Stasis forwards are dispatched
This patch optimizes how forwards are dispatched in Stasis.
Originally, forwards were dispatched as subscriptions that are invoked
on the publishing thread. This did not account for the vast number of
forwards we would end up having in the system, and the amount of work it
would take to walk though the forward subscriptions.
This patch modifies Stasis so that rather than walking the tree of
forwards on every dispatch, when forwards and subscriptions are changed,
the subscriber list for every topic in the tree is changed.
This has a couple of benefits. First, this reduces the workload of
dispatching messages. It also reduces contention when dispatching to
different topics that happen to forward to the same aggregation topic
(as happens with all of the channel, bridge and endpoint topics).
Since forwards are no longer subscriptions, the bulk of this patch is
simply changing stasis_subscription objects to stasis_forward objects
(which, admittedly, I should have done in the first place.)
Since this required me to yet again put in a growing array, I finally
abstracted that out into a set of ast_vector macros in
asterisk/vector.h.
Review: https://reviewboard.asterisk.org/r/2883/
........
r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines
Remove dispatch object allocation from Stasis publishing
While looking for areas for performance improvement, I realized that an
unused feature in Stasis was negatively impacting performance.
When a message is sent to a subscriber, a dispatch object is allocated
for the dispatch, containing the topic the message was published to, the
subscriber the message is being sent to, and the message itself.
The topic is actually unused by any subscriber in Asterisk today. And
the subscriber is associated with the taskprocessor the message is being
dispatched to.
First, this patch removes the unused topic parameter from Stasis
subscription callbacks.
Second, this patch introduces the concept of taskprocessor local data,
data that may be set on a taskprocessor and provided along with the data
pointer when a task is pushed using the ast_taskprocessor_push_local()
call. This allows the task to have both data specific to that
taskprocessor, in addition to data specific to that invocation.
With those two changes, the dispatch object can be removed completely,
and the message is simply refcounted and sent directly to the
taskprocessor.
Review: https://reviewboard.asterisk.org/r/2884/
........
Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
app_queue currently attempts to handle Local channel optimizations in an effort
to provide accurate information in Stasis messages (and their corresponding
AMI events) as well as the Queue log. Sometimes, however, things don't go as
planned.
Consider the following scenario:
SIP/foo <-> L;1 <-> L;2 <-> SIP/agent
SIP/agent answers, triggering a Local channel optimization. app_queue will
normally do the following:
* Listen for the Local optimization events and update our agent accordingly
to SIP/agent in the queue log and messages
* When we get a hangup, publish the AgentComplete event based on our
information (SIP/foo and SIP/agent)
However, as with all things that depend on sanity from something as capricious
as Local channels, things can go wrong:
(1) SIP/agent immediately hangs up upon answering. This triggers a race
condition between termination messages coming from SIP/agent and the
ongoing Local channel optimization messages. (Note that this can also
occur with SIP/foo)
(2) In a race condition, Asterisk can (rarely) deliver the hangup messages
prior to the Local channel optimization.
In that case, the messages *may* arrive to app_queue in the following order:
* Hangup SIP/Agent
* Hangup SIP/foo
* Optimize L;1/L;2
* Hangup L;2
* Hangup L;1
When app_queue receives the hangup of the agent or the caller, it will attempt
to publish the AgentComplete event. However, it now has a problem - it thinks
its agent is the ;1 side of the Local channel, as it never received the
optimization event. At the same time, that channel is already gone. This
results in getting NULL from the Stasis cache. What's more, we can't really
wait for the optimization message, as we are currently handling the hangup
of the channel that the optimization event would tell us to use.
This patch modifies the behavior in app_queue such that, since we still have a
lot of pertinent queue information (interface, queue name, etc.), we now raise
the event with what information we know. The channels involved now may or may
not be present. Users will still at least get the "AgentComplete" event, which
"completes" the known Agent information.
Review: https://reviewboard.asterisk.org/r/2878/
(closes issue ASTERISK-22507)
Reported by: Richard Mudgett
........
Merged revisions 400060 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400061 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the channel variable MONITOR_EXEC is set, app_queue will pass the specified
execution parameters to the MixMonitor application when a queue is recorded.
If that channel variable is not set, the buffer that holds the escaped value
was not being initialized to NULL, and so would be passed to the MixMonitor
application with garbage. Hilarity ensued as app_mixmonitor attempted to
execute gobeldy-gook.
........
Merged revisions 399681 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r397921 | mmichelson | 2013-08-29 10:42:10 -0500 (Thu, 29 Aug 2013) | 6 lines
Resolve assumptions that bridge snapshots would be non-NULL for transfer stasis events.
Attempting to transfer an unbridged call would result in crashes in either CEL code or
in the conversion to AMI messages.
........
r397922 | mmichelson | 2013-08-29 10:42:29 -0500 (Thu, 29 Aug 2013) | 3 lines
Remove extra debug message.
........
Merged revisions 397921-397922 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397923 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This essentially makes app_queue usable again. From reviewboard:
* Reporting of transfers and call completion is done by creating stasis
subscriptions and listening for specific events in order to determine
when the call is finished (either via a transfer or hangup).
* Dial end messages have been added where they were previously missing.
* Queue stats are properly being updated again once calls have finished.
* AgentComplete stasis messages and AMI events are now occurring again.
* Mixmonitor starting has been factored into its own function and uses the
Mixmonitor API now instead of using ast_pbx_run()
In addition to the changes in app_queue, there are several supplementary changes as well:
* Queue logging now differentiates between attended and blind transfers. A
note about this is in the CHANGES file.
* Local channel optimization events now report more information. This
includes which of the two local channels involved is the destination of
the optimization, the channel that is replacing the destination local channel,
and an identifier so that begin and end events can be matched to each other.
The end events are now sent whether the optimization was successful or not and
includes an indicator of whether the optimization was successful.
* Changes were made to features and bridging_basic so that additional flags may
be set on a bridge. This is necessary because the queue requires that its
bridge only allows move-swap local channel optimizations into the bridge.
(closes issue ASTERISK-21517)
Reported by Matt Jordan
(closes issue ASTERISK-21943)
Reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2694
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397451 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Queue members who happen to be in multiple queues at the same time may not
have any wrap up time. This problem occurred due to a code change in Asterisk
11.3.0 that unified device state tracking of Queue members in multiple
Queues (which fixed some other problems, but unfortunately caused this one).
This patch fixes the behavior by having the is_member_available function
check the queue's wrap up time and the time of the member's last call, such
that for a particular queue, the member won't be considered available if their
last call is within the wrap up time.
(closes issue ASTERISK-22189)
Reported by: Tony Lewis
Tested by: Tony Lewis
........
Merged revisions 396948 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This removes unused code, event types, IE pltypes, and event IE types
where possible and makes several functions private that were once
public. This includes a renumbering of the remaining event and IE types
which breaks binary compatibility with previous versions. The last
remaining consumers of the old event system (or parts thereof) are
main/security_events.c, res/res_security_log.c, tests/test_cel.c,
tests/test_event.c, main/cel.c, and the CEL backends.
Review: https://reviewboard.asterisk.org/r/2703/
(closes issue ASTERISK-22139)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The rna() routine will raise a Stasis message involving both the caller and the
agent. This doesn't work so well if we already hung up the agent channel, as
the channel doesn't quite exist. Not surprisingly, this will crash. This patch
properly runs the rna subroutine (performing all of the Ring-No-Answer logic)
prior to hanging up the agent channel.
(closes issue ASTERISK-22258)
Reported by: Kiril Valchev
Tested by: Kiril Valchev
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the ability in Queue to raise a hint when a member's paused
state changes. The hint uses the form 'Queue:{queue_name}_pause_{member_name}',
where {queue_name} and {member_name} are the name of the queue and the name
of the member to subscribe to, respectively.
For example: exten => 8501,hint,Queue:sales_pause_mark.
Members will show as In Use when paused.
Note that the format of the queue pause hint was changed slightly from what
is on the issue to accomodate suggestion on the code review.
Review: https://reviewboard.asterisk.org/r/2254
(closes issue ASTERISK-20842)
Reported by: Philippe Lindheimer
patches:
qpause-10-378206.diff uploaded by Philippe Lindheimer (license 5519)
qpause-11-378206.diff uploaded by Philippe Lindheimer (license 5519)
qpause-trunk-378206.diff uploaded by Philippe Lindheimer (license 5519)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents XML documentation duplication by expanding channel and
bridge snapshot tags into channel and bridge snapshot parameter sets
with a given prefix or defaulting to no prefix. This also prevents
documentation from becoming fractured and out of date by keeping all
variations of the documentation in template form such that it only
needs to be updated once and keeps maintenance to a minimum.
Review: https://reviewboard.asterisk.org/r/2708/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395985 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch renames the bridging* files to bridge*. This may seem pedantic
and silly, but it fits better in line with current Asterisk naming conventions:
* channel is not "channeling"
* monitor is not "monitoring"
etc.
A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is
the act of using a bridge on a set of channels - and the API that fulfills that
role is more than just the action.
(closes issue ASTERISK-22130)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
When QUEUE_MEMBER is used and the member specified is not in the queue,
Asterisk provides an ERROR message that indicates that the option specified
is not valid. This patch now properly displays an ERROR message that the
member is not in the queue if an interface is specified.
(closes issue ASTERISK-21980)
Reported by: Avraam David
........
Merged revisions 394345 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394346 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 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
In r386792, the ability to play prompts to the first caller in a call queue was
added. While this is arguably a bug fix for those who expect the first caller
to continue receiving prompts while the agent is dialed, it has the side effect
of preventing the first caller from hearing the agent immediately upon
bridging. This may not be a problem for those who really want this option, but
for those who didn't care whether or not the first caller in queue heard their
position, it was an issue.
This patch disables the ability for the first caller in the queue to hear
prompts and adds a new option, announce-to-first-user, to queues.conf. Those
who the behavior can enable it by setting this value to True.
Note that if we ever implement the ability to have the prompts be stopped
upon bridging, this option can be removed.
(closes issue ASTERISK-21782)
Reported by: Remi Quezada
........
Merged revisions 391215 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 391241 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391245 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Breaks many things until they can be reworked. A partial list:
chan_agent
chan_dahdi, chan_misdn, chan_iax2 native bridging
app_queue
COLP updates
DTMF attended transfers
Protocol attended transfers
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r388005, macros were introduced to consistently define message
types. This added an assert if a message type was used either before
it was initialized or after it had been cleaned up. It turns out that
this assertion fires during shutdown.
This actually exposed a hidden shutdown ordering problem. Since
unsubscribing is asynchronous, it's possible that the message types
used by the subscription could be freed before the final message of
the subscription was processed.
This patch adds stasis_subscription_join(), which blocks until the
last message has been processed by the subscription. Since joining was
most commonly done right after an unsubscribe, a
stasis_unsubscribe_and_join() convenience function was also added.
Similar functions were also added to the stasis_caching_topic and
stasis_message_router, since they wrap subscriptions and have similar
problems.
Other code in trunk was refactored to join() where appropriate, or at
least verify that the subscription was complete before being
destroyed.
Review: https://reviewboard.asterisk.org/r/2540
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the "ignorebusy" setting was deprecated, we added some code to allow us to
be compatible with older setups that are still using the "ignorebusy" setting
instead of "ringinuse". We set a char *variable with the column name to use,
which helps the realtime functions to use the correct column in their SQL
queries. When "persistentmembers" is enabled, we are not setting this variable
before the realtime functions were called to load members. This results in the
variable being NULL and therefore causing a segfault when loading members during
the module's process of loading.
The solution was to move the code that sets that variable to be before these
realtime functions are called during the loading of the module.
(closes issue ASTERISK-21738)
Reported by: JoshE
Tested by: JoshE
Patches:
asterisk-21738-rt-ringinuse-field-not-set.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2499/
........
Merged revisions 388108 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388110 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the move from Asterisk's event system to Stasis, this makes
distributed device state aggregation always-on, removes unnecessary
task processors where possible, and collapses aggregate and
non-aggregate states into a single cache for ease of retrieval. This
also removes an intermediary step in device state aggregation.
Review: https://reviewboard.asterisk.org/r/2389/
(closes issue ASTERISK-21101)
Patch-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385860 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The core module related to coloring terminal output was old and needed
some love. The main thing here was an attempt to get rid of the
obscene number of stack-local buffers that were allocated for no other
reason than to colorize some output. Instead, this uses a simple trick
to allocate several buffers within threadlocal storage, then
automatically rotates between them, so that you can make multiple calls
to the colorization routine within one function and not need to
allocate multiple buffers.
Review: https://reviewboard.asterisk.org/r/2241/
Patches:
bug.patch uploaded by Tilghman Lesher
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381448 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When ringinuse=no queue members can receive more than one call if these
calls happen at nearly the same time.
* Fix so a queue member does not receive more than one call from a queue.
NOTE: This fix does not prevent multiple calls to a member if the member
is in more than one queue.
* Did some refactoring to eliminate some code redundancy.
(issue ASTERISK-16115)
Reported by: nik600
Patches:
jira_asterisk_16115_single_q_v1.8.patch (license #5621) patch uploaded by rmudgett
Modified
* Revert the -r341580 and -r341599 changes adding the queues.conf
check_state_unknown option as it was added in an attempt to fix this
problem. The fix did not need to be optional. The fix should not have
tried to explicitly set the device state. Setting the device state by
something other than the device introduces a race condition. I also could
not see how the change would be effective other than delaying the
app_queue code long enough for the device state to propagate to app_queue.
........
Merged revisions 378663 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378683 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 378687 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the "h" extension is present within the context of the queue, all calls
are being reported COMPLETECALLER even when the agent is hanging up the call.
This patch checks to see if the agent hung-up or not instead of only relying on
checking if the queue (caller) channel hung-up or not. It would appear that
having the h extension in the mix, the pbx goes to the h extension,
"hanging-up" the queue channel and triggering the reporting of COMPLETECALLER.
(closes issue ASTERISK-20743)
Reported by: call
Tested by: call, Michael L. Young
Patches:
asterisk-20743-q-cmplt-caller.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2256/
........
Merged revisions 378514 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378515 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378516 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk maintains an internal cache for devices in the event subsystem. The
device state cache holds the state of each device known to Asterisk, such that
consumers of device state information can query for the last known state for
a particular device, even if it is not part of an active call. The concept of
a device in Asterisk can include entities that do not have a physical
representation. One way that this occurred was when anonymous calls are allowed
in Asterisk. A device was automatically created and stored in the cache for
each anonymous call that occurred; this was possible in the SIP and IAX2
channel drivers and through channel drivers that utilized the
res_jabber/res_xmpp resource modules (Gtalk, Jingle, and Motif). These devices
are never removed from the system, allowing anonymous calls to potentially
exhaust a system's resources.
This patch changes the event cache subsystem and device state management to
no longer cache devices that are not associated with a physical entity.
(issue ASTERISK-20175)
Reported by: Russell Bryant, Leif Madsen, Joshua Colp
Tested by: kmoore
patches:
event-cachability-3.diff uploaded by jcolp (license 5000)
........
Merged revisions 378303 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378320 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 378321 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378322 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With the option ringinuse=no set, the patch committed for ASTERISK-16115
causes non-SIP queue members to never be called because the device state
is checked after a channel is created to determine if the member is busy.
These queue members always get the "Member %s is busy, cannot dial"
message.
Most channel drivers other than chan_sip use the default device state
handling. The default device-state state is considered in use or unknown
if the channel exists or not respectively.
(closes issue ASTERISK-20801)
Reported by: rmudgett
Patches:
jira_asterisk_16115_revert_r370418_v1.8.patch (license #5621) patch uploaded by rmudgett
........
Merged revisions 378036 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378037 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 378038 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378039 65c4cc65-6c06-0410-ace0-fbb531ad65f3
