These commands work much like the dialplan applications that would otherwise invoke them.
A nice benefit of these is that they can be invoked on a call remotely and at any time
during a call. They work much like the Monitor and StopMonitor ami commands.
(closes issue ASTERISK-17726)
Reported by: Sergio González Martín
Patches:
mixmonitor_actions.diff uploaded by Sergio González Martín (license 5644)
Review: https://reviewboard.asterisk.org/r/1193/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@347903 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a caller sends DTMF while the SayUnixTime application is saying the time, The call
would jump to the next extension much like it does during Background(). This patch adds
option 'j' to SayUnixTime which when used employs the old behavior. Also, this patch
allows arguments to sayunixtime to not be used as empty strings in the case of something
like 'sayunixtime(,,,j)' or 'sayunixtime(,,pattern).
(closes issue ASTERISK-16675)
Reported by: jlpedrosa
Patches:
patch_SayUnixTime_noJump.patch uploaded by jlpedrosa (license 5959)
Review: https://reviewboard.asterisk.org/r/956/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@347866 65c4cc65-6c06-0410-ace0-fbb531ad65f3
r325483 caused a regression in Asterisk 10+ that would make Asterisk segfault when
attempting to set penalty on an interface without specifying a queue in the queue set
penalty CLI command. In addition, no attempt would be made whatsoever to perform the
penalty setting on all the queues in the core list with either the cli command or the
non-segfaulting ami equivalent. This patch fixes that and also makes an attempt to
document and rename some functions required by this command to better represent what
they actually do. Oh yeah, and the use of this command without specifying a specific
queue actually works now.
Review: https://reviewboard.asterisk.org/r/1609/
........
Merged revisions 347656 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@347658 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Meetme would attempt to substitute the realtime values of RECORDING_FILE and
RECORDING_FORMAT from the meetme db entry instead of using the channel variable set
for those variables in spite of those database entries being NULL or even lacking
a column to represent them.
(closes issue ASTERISK-18873)
Reported by: Byron Clark
Patches:
ASTERISK-18873-1.patch uploaded by Byron Clark (license 6157)
........
Merged revisions 347369 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 347383 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@347395 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds two new menu features to app_confbridge, admin_toggle_menu_
participants and participant_count. The admin action will globally mute /
unmute all non-admin participants on a converence, while the participant
count simply exposes the existing participant count function to the
conference bridge menu.
This also adds configuration options to change the sound played when the
conference is globally muted / unmuted, as well as the necessary config
hooks to place these functions in the DTMF menus.
(closes issue ASTERISK-18204)
Reported by: Kevin Reeves
Tested by: Matt Jordan
Patches:
app_confbridge.c.patch.txt, conf_config_parser.c.patch.txt,
confbridge.h.patch.txt uploaded by Kevin Reeves (license 6281)
Review: https://reviewboard.asterisk.org/r/1518/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@345560 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It was strange that the AgentCalled AMI event would get most of its
information from the incoming channel but then get the CallerID
information from the outgoing channel. Before connected line support was
added, this information was always the same at this point.
(closes issue ASTERISK-18152)
Reported by: Thomas Farnham
Tested by: rmudgett
........
Merged revisions 344536 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 344537 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@344538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The MeetMe application documentation has some comments about usage of DAHDI,
and they were a bit outdated relative to modern DAHDI releases. This patch
changes the comment to just tell the user that a functional DAHDI timing
source is required, and no longer mention 'dahdi_dummy', since that module
does not exist in current DAHDI releases.
........
Merged revisions 342990 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 342991 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@342992 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Despite an ominous sounding comment stating that membercount was for "logged
in" members only and thus we couldn't use ao2_container_count(), I could not
find a single place in the code where that seemed to be accurate. The only time
we decremented membercount was when we were marking something dead or actually
removing it. The only places we incremented it were either after ao2_link(), or
trying to correct for having set it to 0 during a reload. In every case where
we were correcting the value, it seemed that we were trying to make the count
actually match what ao2_container_count() would return. The only place I could
find where we made a determination about something being "logged in" or not, we
didn't trust the membercount, but instead looked at devicestate, paused, etc.
This patch removes membercount, replaces its use with ao2_container_count, and
manually adds the results of ao2_container_count to a "membercount" field for
ast_data queue query results. This patch also would fix AST-676, but as it is
slightly riskier than the previously committed fix, the two commits have been
made separately.
Reivew: https://reviewboard.asterisk.org/r/1541/
........
Merged revisions 342383 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 342384 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@342385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
To use the new OBJ_KEY flag, the container hash and compare callback
functions must be updated to support OBJ_KEY. Otherwise, bad things
happen.
(issue ASTERISK-14769)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@342112 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
........
r341580 | irroot | 2011-10-20 19:13:23 +0200 (Thu, 20 Oct 2011) | 15 lines
Add option to check state when state is unknown
r341486 reverts r325483 this is a rework of the patch.
optimize to minimize load.
add option check_state_unknown to control whether a member with unknown
device state is checked there is a small % chance that calls will be sent
to the member when they on a call.
app_queue will see a device with unknown state as available and does not
try verify the state without this option enabled.
Review: https://reviewboard.asterisk.org/r/1535/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@341583 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
........
r341486 | mnicholson | 2011-10-19 16:23:17 -0500 (Wed, 19 Oct 2011) | 18 lines
Fix a performance regression introduced in r325483.
The regression was caused by a call to ast_parse_device_state() in app_queue's
ring_entry() function. The ast_parse_device_state() function eventually calls
ast_channel_get_full() with a channel name prefix which causes it to walk the
channel list causing massive lock contention and slow downs.
This patch fixes the regression by removing the call to
ast_parase_device_state() which should be unnecessary. Queue member device
state should be maintained by device state events. Some users have seen
instances where busy agents were called when they shouldn't have, which is the
reason the call to ast_parse_device_state() was added. That change appears to
have resolved that issue but also causes this performance regression. There may
still be issues with queue member status, and if so, alternative methods should
be investigated to resolve them.
AST-695
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@341487 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r340109 | mnicholson | 2011-10-10 09:15:41 -0500 (Mon, 10 Oct 2011) | 18 lines
Merged revisions 340108 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r340108 | mnicholson | 2011-10-10 09:14:48 -0500 (Mon, 10 Oct 2011) | 11 lines
Load the proper XML documentation when multiple modules document the same application.
This patch adds an optional "module" attribute to the XML documentation spec
that allows the documentation processor to match apps with identical names from
different modules to their documentation. This patch also fixes a number of
bugs with the documentation processor and should make it a little more
efficient. Support for multiple languages has also been properly implemented.
ASTERISK-18130
Review: https://reviewboard.asterisk.org/r/1485/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@340110 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r337974 | rmudgett | 2011-09-26 14:35:23 -0500 (Mon, 26 Sep 2011) | 37 lines
Merged revisions 337973 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r337973 | rmudgett | 2011-09-26 14:30:39 -0500 (Mon, 26 Sep 2011) | 30 lines
Fix deadlock when using dummy channels.
Dummy channels created by ast_dummy_channel_alloc() should be destoyed by
ast_channel_unref(). Using ast_channel_release() needlessly grabs the
channel container lock and can cause a deadlock as a result.
* Analyzed use of ast_dummy_channel_alloc() and made use
ast_channel_unref() when done with the dummy channel. (Primary reason for
the reported deadlock.)
* Made app_dial.c:dial_exec_full() not call ast_call() holding any channel
locks. Chan_local could not perform deadlock avoidance correctly.
(Potential deadlock exposed by this issue. Secondary reason for the
reported deadlock since the held lock was part of the deadlock chain.)
* Fixed some uses of ast_dummy_channel_alloc() not checking the returned
channel pointer for failure.
* Fixed some potential chan=NULL pointer usage in func_odbc.c. Protected
by testing the bogus_chan value.
* Fixed needlessly clearing a 1024 char auto array when setting the first
char to zero is enough in manager.c:action_getvar().
(closes issue ASTERISK-18613)
Reported by: Thomas Arimont
Patches:
jira_asterisk_18613_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: Thomas Arimont
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@337975 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r337120 | mjordan | 2011-09-20 17:49:36 -0500 (Tue, 20 Sep 2011) | 28 lines
Merged revisions 337118 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r337118 | mjordan | 2011-09-20 17:38:54 -0500 (Tue, 20 Sep 2011) | 21 lines
Fix for incorrect voicemail duration in external notifications
This patch fixes an issue where the voicemail duration was being reported
with a duration significantly less than the actual sound file duration.
Voicemails that contained mostly silence were reporting the duration of
only the sound in the file, as opposed to the duration of the file with
the silence. This patch fixes this by having two durations reported in
the __ast_play_and_record family of functions - the sound_duration and the
actual duration of the file. The sound_duration, which is optional, now
reports the duration of the sound in the file, while the actual full duration
of the file is reported in the duration parameter. This allows the voicemail
applications to use the sound_duration for minimum duration checking, while
reporting the full duration to external parties if the voicemail is kept.
(issue ASTERISK-2234)
(closes issue ASTERISK-16981)
Reported by: Mary Ciuciu, Byron Clark, Brad House, Karsten Wemheuer, KevinH
Tested by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1443
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@337124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r336659 | rmudgett | 2011-09-19 13:51:19 -0500 (Mon, 19 Sep 2011) | 38 lines
Merged revisions 336658 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r336658 | rmudgett | 2011-09-19 13:46:40 -0500 (Mon, 19 Sep 2011) | 31 lines
Made Dial d and H options no longer immediately auto-answer the calling leg.
The Dial d and H options break DTMF attended transfer atxferdropcall
option.
1) Party A calls party B.
2) Party B does a DTMF attended transfer to Party C.
If the dialplan uses the Dial d or H options to call Party C then the Dial
application answers the call immediately before initiating the call leg to
Party C. The premature answer causes the transfer code to not invoke the
atxferdropcall=no behavior for a blonde transfer since Party C has
"answered". The transfer code thinks that Party B has "consulted" with
Party C when Party B hangs up and completes the transfer to Party A.
Party A now hears ringback until Party C actually answers.
ASTERISK-13294 Dial d option.
ASTERISK-11067 Dial H option to disconnect before answer.
The referenced issues made Dial answer with the d and H options because
many SIP and ISDN phones cannot send DTMF before the call is connected.
* Made require the dialplan to control when or if the call needs to be
answered to use the Dial application d and H options. (The call is no
longer surprise answered when using the Dial d or H options.)
Review: https://reviewboard.asterisk.org/r/1381/
JIRA AST-623
JIRA AST-666
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@336662 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r336094 | irroot | 2011-09-15 17:54:46 +0200 (Thu, 15 Sep 2011) | 26 lines
Merged revisions 336093 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r336093 | irroot | 2011-09-15 17:46:21 +0200 (Thu, 15 Sep 2011) | 20 lines
Locking order in app_queue.c causes deadlocks.
a channel lock must never be held with the queues container lock held.
the deadlock occured on masquerade.
the queues container lock is a relic of the past the old queue module lock.
with ao2 there is no need to hold this lock when dealing with members this
patch removes unneeded locks.
(closes issue ASTERISK-18101)
(closes issue ASTERISK-18487)
Reported by: Paul Rolfe, Jason Legault
Tested by: irroot, Jason Legault, Paul Rolfe
Reviewed by: Matthew Nicholson
Review: https://reviewboard.asterisk.org/r/1402/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@336095 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
........
r336042 | oej | 2011-09-15 14:46:38 +0200 (Tor, 15 Sep 2011) | 12 lines
Meetme: Introducing a new option "k" to kill a conference if there's only a single member left.
When using Meetme as a modular call bridge from third party applications, it's handy to make
it behave like a normal call bridge. When the second to last person exists, the last person
will be kicked out of the conference when this option is enabled.
(closes issue ASTERISK-18234)
Review: https://reviewboard.asterisk.org/r/1376/
Patch by oej, sponsored by ClearIT, Solna, Sweden
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@336043 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Jonathan Rose
Walter Doekes
Tilghman Lesher
Paul Belanger
Matthew Jordan
Richard Mudgett
TransNexus OSP Development
Kinsey Moore
Leif Madsen
Kevin P. Fleming
Terry Wilson
Gregory Nietsky
Matthew Nicholson
Olle Johansson