Previously, realtime queues could be loaded without defining the queue member
table. This allowed for queue members to be dynamic, while the realtime
queue definitions could exist in some backing storage. Revision 342223 broke
this when it changed the return value for realtime_multientry to return NULL
when no results are returned. Previously, an empty ast_config object was
expected.
(closes issue ASTERISK-19170)
Reported by: Rene Mendoza
Tested by: Rene Mendoza
Patches:
rt_queue_member_patch.diff uploaded by Matt Jordan (license 6283)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@350552 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Like Dial and Queue, FollowMe needs to deal with
AST_CONTROL_CONNECTED_LINE information so when the parties are initially
bridged, the connected line information will be correct.
* Added the 'I' option just like the app_dial and app_queue 'I' option.
(closes issue ASTERISK-18969)
Reported by: rmudgett
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1656/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@350364 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If SLA was reloaded without the config file being changed, current settings got
wiped out before the SLA reload code decided it wasn't going to reload the file
since nothing was changed. Moving the settings reset later in the reload
process fixes this.
(closes issue AST-744)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@350023 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When ChanSpy is initialized it creates and attaches 3 audiohooks:
1) Read audio off of the channel that we are spying on
2) Write audio to the channel that we are spying on
3) Write audio to the channel that is bridged to the channel that we are
spying on.
The first is always necessary, but the others are used only when specific
options are passed to the ChanSpy application (B, d, w, and W to be specific).
When those flags are not passed, neither of those audiohooks are ever sent
frames, but we still try to process the hooks for each voice frame that we
recieve on the channel.
So in short - only create and attach audiohooks that we actually need.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@349044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ast_cdr_setcid() and ast_cdr_update() were shown in ASTERISK-18836 to
be called by different threads for the same channel. The channel driver
thread and the PBX thread running dialplan.
* Add lock protection around CDR API calls that access an ast_channel
pointer.
(closes issue ASTERISK-18836)
Reported by: gpluser
Review: https://reviewboard.asterisk.org/r/1628/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@348362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ParkAndAnnounce tried to pass the CallerID to the announcing channel but
the ID was wiped out by the channel masquerade done when parking the call.
* Save the CallerID before parking the channel to pass it to the
announcing channel.
* Fixed a minor memory leak in ParkAndAnnounce.
* Updated some ParkAndAnnounce log messages.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@348310 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The addition of the Connected Line support changed how CallerID is passed
to outgoing calls. The FollowMe application was not updated to pass
CallerID to the outgoing calls.
* Fix FollowMe CallerID on outgoing calls.
* Restructured findmeexec() to fix several memory leaks and eliminate some
duplicated code.
* Made check the return value of create_followme_number(). Putting a NULL
into the numbers list is bad if create_followme_number() fails.
* Fixed a couple uses of ast_strdupa() inside loops.
* The changes to bridge_builtin_features.c fix a similar CallerID issue
with the bridging API attended and blind transfers. (Not used at this
time.)
(closes issue ASTERISK-17557)
Reported by: hamlet505a
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1612/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@348101 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)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@347369 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The voicemail [general] zonetag and locale variables weren't loaded
until after the mailboxes were initialized. This caused the settings to
be unset for those mailboxes until a reload was performed.
(closes issue ASTERISK-18838)
Review: https://reviewboard.asterisk.org/r/1570
Reviewed by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@347111 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Before, using the U flag in Voicemail with multiple recipients would put urgent messages
in the INBOX folder for all users past the first thanks to a bug with the message
copying function. This would also cause messages to fail to be sent if the INBOX
directory hadn't been created for that mailbox yet.
(closes issue ASTERISK-18245)
Reported by: Matt Jordan
(closes issue ASTERISK-18246)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1589/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@345487 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change was made because forcegreeting and forcename settings in voicemail could be
circumvented by hanging up after entering a password, because the only way voicemail
currently observes whether a mailbox is new or not is by checking to see if the password
is the same as the mailbox number or not.
(closes issue ASTERISK-18282)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1581/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@345062 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fixed app_queue.c:ring_entry() calling ast_call() with the channel locks
held. Chan_local attempts to do deadlock avoidance in its ast_call()
callback and could deadlock if a channel lock is already held.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@344539 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@344536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes an issue where a user of a dynamic conference was asked for a PIN
twice. This also adds documentation to assist in future modifications to the
piece of code responsible for PIN checking.
(closes issue AST-670)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@344439 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The last time this code was touched (by me), a subtlety was missed based on the
difference between needing to check a pin's validity and the need to prompt
for a pin.
(closes issue ASTERISK-18488)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@344102 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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@342990 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@342383 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ASTERISK-12175 changed the p and X options to not interfere with the s
option when they are used together. It makes more sense for the s option
to have priority for the DTMF '*' key since it cannot change its
activation code. Otherwise, you could not use option s with the p or X
options.
JIRA AST-671
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@340470 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@340108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@337973 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@337118 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@336658 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@336093 65c4cc65-6c06-0410-ace0-fbb531ad65f3
