I wonder if Asterisk can run at all without res_features. My guess is that
there's propably a lot of more modules and the core that depends on it.
Reported by: caio1982
(closes issue #11574)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@93182 65c4cc65-6c06-0410-ace0-fbb531ad65f3
rizzo brought up some issues related to the way that the metadata required
for menuselect and the rest of the build system is extracted from the source
files. Since I had a few hours to kill on an airplane today, I decided to
improve this situation... so now the system caches the extracted metadata
and uses it to build the menuselect 'tree' as much as it can. The result
of this is that when a single source file is changed, only the metadata for
that file needs to be extracted again, and the rest is used from the cache
files. I also reduced the number of forked processes required to do the
metadata extraction; it was actually possible to do most of what we needed
in the Makefiles themselves without using any shell scripts at all! On my
laptop, these changes resulted in an 80% decrease in the time required
for the 'menuselect.makeopts' automatic check to occur after editing a single
source file.
While doing this work I also cleaned up a few minor things in the Makefiles,
adding a check for 'awk' to the configure script and changed all remaining
places we use 'grep' or 'awk' to use the ones found by the configure script,
and changed the 'prep_tarball' script to build the menuselect metadata so
that tarballs of Asterisk will include it and won't require the user to
wait while it is extracted after unpacking.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@93180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
caller were ringing members (but not yet bridged) there could be available members
and waiting callers who would not get matched up. The member availability checker
was correctly determining the number of available members in this scenario, but
the queue itself did not parallelly reflect this status on the pending calls. This
commit corrects the issue.
(closes issue #11459, reported by equissoftware, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92323 65c4cc65-6c06-0410-ace0-fbb531ad65f3
duplicate dialed numbers will be skipped, meaning the datastore isn't created. This means
that when we try to free it, there's a crash. This stops that crash from occurring.
(closes issue #11499, reported by slavon, patched by eliel)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92202 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to be locked.
* Document why we don't record Local channels in the dialed interfaces list.
* Remove the dialed variable as it isn't needed.
* Restructure some code for clarity and coding guidelines stuff
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to be locked.
* Document why we don't record Local channels in the dialed interfaces list.
* Handle memory allocation failure.
* Remove the dialed variable, as it wasn't actually needed.
* Tweak some formatting to conform to coding guidelines.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
on every call into a queue. I'm not entirely sure about the logic in this part
of the code, so I want to look at it some more tomorrow. However, this makes
it safe and keeps it from crashing.
(closes issue #11486, reported by adamg, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of crashing if a user had more than 256 messages in their voicemail. This patch kills two birds with
one stone by adding maxmsg support and also setting a hard limit on the number of messages at 255 so
that the crashes cannot happen.
(closes issue #11101, reported by Skavin, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
provided. This was due to the fact that the answering channel did not have an extension
set, so ast_parseable_goto would fail. This fix eliminates the call to ast_parseable_goto
on the answering channel since it is a wasteful call. The answering channel and the calling
channel are both directed to the same extension and context, just different priorities, so
we can just copy the values from the calling channel to the answering channel and increment
the answering channel's priority.
(closes issue #11382, reported by jon, patch by me with correction by jon)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91273 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@90735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
change, I added some code to set pointers to NULL after they were unreferenced.
This pointed out that in this place, the object was unreferenced before the
code was done using it. So, move the unref down a little bit.
(crash reported by jmls on IRC)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@90470 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now, it automatically increases the reference count to reflect the reference
that is now held by the container.
This was done to be more consistent with ao2_unlink(), which automatically
releases the reference held by the container. It also makes it so it is
no longer possible for a pointer to be invalid after ao2_link() returns.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@90348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since greetings are not retrieved from IMAP anyway, it is pointless to attempt storing them there.
(closes issue #11359, reported by spditner, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89999 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) Due to some signed vs. unsigned silliness, setting 'eventwhencalled' to
'vars' or 'yes' did exactly the same thing. Thus the sign change of the
ast_true call.
2) The vars2manager function overwrote a \n for every channel variable it parsed, resulting
in bizarre output for the channel variables. This patch remedies this.
(related to issue #11385, however I'm not sure if this will actually be enough to close it)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89837 65c4cc65-6c06-0410-ace0-fbb531ad65f3
app_playback will continue to try to play the remaining files. With this change, no more files will
be played back upon hangup.
(closes issue #11345, reported and patched by IgorG)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89618 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change fixes the problem, with a multi-faceted approach. First, we
do our best to avoid these messages from being created in the first place,
and second, if that fails, we detect when the voicemail message is
zero-length and avoid exiting at that point.
Reported by: dtyoo
Patch by: gkloepfer,tilghman
(Closes issue #11083)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89540 65c4cc65-6c06-0410-ace0-fbb531ad65f3
has a call out to the station, but the user has pressed a line button to answer
the call instead of picking up the handset. If they do, the phone sends out a
new INVITE. So, the SLAStation app must check to see if it is picking up a
ringing trunk, and ensure that the other stations stop ringing.
(reported internally, patched by me, tested by mogorman)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89296 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and args.post_process strings are uninitialized and could contain garbage. This change
handles this situation properly by only using arguments that we have parsed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A huge thanks go to lvl- for patiently providing the necessary valgrind output
that was necessary to finding this problem of memory corruption.
Reported by: lvl-
Patch by: tilghman
Closes issue #11174
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89093 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and ast_string_field_free_all to ast_string_field_reset_all
to avoid misuse (due to too similar names and an error in
documentation). Fix two related memory leaks in app_meetme.
No need to merge to trunk, different fix already applied there.
Not applicable to 1.2
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@88471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
since the code attempts to set the strategy to -1 if you specify a bogus strategy.
While this isn't a huge issue in 1.4, it could be a problem for someone who, say, tries
to use the roundrobin strategy in trunk (despite all the deprecation warnings in 1.4).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@86202 65c4cc65-6c06-0410-ace0-fbb531ad65f3
interesting (read nasty) situations. This patch clears up the issue by making
only dynamic queue members removable via dynamic methods.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85958 65c4cc65-6c06-0410-ace0-fbb531ad65f3
change. I changed this a while ago in trunk for performance reasons. However,
bug 8407 points out that it is actually a race condition, causing device state
changes to get processed in random order. So, I backported my changes from
trunk to 1.4.
(closes issue #8407, patch provided by tim_ringenbach, committed patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
time to execute while not servicing the channel. So, put the channel in
autoservice while the command is being executed.
(closes issue #10726, reported by mnicholson)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@83179 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of just saying that it is generally a worthless feature.
(Thanks to Jim Van Meggelen for pointing it out and providing the proposed text)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82992 65c4cc65-6c06-0410-ace0-fbb531ad65f3
was fixed by running Asterisk under valgrind.
(closes issue #10746, reported by arcivanov, patched by me)
*** IMPORTANT NOTE: We need to check to see if this same bug exists elsewhere.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82644 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk will log a warning message letting the user know that one was already defined with that
name and is it skipping all further instances. This also will work for realtime queues but in order
for that to happen, the user would have to trigger a perfectly timed reload as a realtime queue is being
looked up, which is highly unlikely (but taken care of nonetheless).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82326 65c4cc65-6c06-0410-ace0-fbb531ad65f3
from being reallocated every time the queue is accessed.
I also removed a debug message I had accidentally left in on a previous commit.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82274 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When building the outgoing list in try_calling(), a member reference is stored
in each outgoing entry. However, when this list got destroyed, the reference
was not released.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82263 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to 'mem_iter' so that when refcounted queues are merged into trunk, there will be
little confusion regarding iterator names, especially when a queue and member iterator
are used in the same function.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82252 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: stevefeinstein
Patches:
meetme-unmute-manager.diff uploaded by qwell (license 4)
Tested by: stevefeinstein
After looking over the code I agree with Qwell. Setting the file descriptor to conference each time just causes a fight back and forth.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81776 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a realtime queue had callers waiting in it, then the queue would be removed from the queue list, but it would
not actually be freed (in fact, a debug message warning about a memory leak would come up). With this patch,
reloads do not touch realtime queues at all.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
streaming functions will report it. Secondly, not all non-zero returns from play_file mean that the announce file
wasn't found. Positive return values simply mean that a digit was pressed (most likely to skip through the announcement).
(closes issue #10612, reported and patched by dimas)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81397 65c4cc65-6c06-0410-ace0-fbb531ad65f3
changes in the realtime engine.
(issue #10424, reported by irroot, patch by me)
This patch creates a new function called update_realtime_member_field, which is a generic
function which will allow any one field of a realtime queue member to be updated. This patch
only uses this function to update the paused status of a queue member, but it lays the foundation
for persisting the state of a realtime member the same way that static members' state is maintained
when using the persistentmembers setting
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81349 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue 10541, reported by Alric, patched by me)
The REALLY nice things about this patch is that queue members now have a "realtime" field
which will be true if the member is a realtime member. This means we can check this value
prior to certain processing if it should ONLY be done for realtime members.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81340 65c4cc65-6c06-0410-ace0-fbb531ad65f3
locked, and then each individual queue is locked. Under the right circumstances, this could deadlock. As such, I have unlocked
the individual queue before locking the queue list, and then locked the queue back after the queue list is unlocked.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a retrieval of a greeting from the database fails, but the file is found on the file system, then
we go ahead an insert the greeting into the database. The result of this is that people who
switch from file storage to ODBC storage do not need to rerecord their voicemail greetings.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79906 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1. instead of using inboxcount as the core message counting function, we use messagecount instead. This makes it possible to count messages in folders besides just INBOX and Old.
2. inboxcount and hasvoicemail now use messagecount as their means of determining return values.
3. Added a copy_message function for IMAP storage. Unfortunately I don't have the means to test it, but it seems like a pretty straightforward function.
4. Removed a #ifndef IMAP_STORAGE and matching #endif from leave_voicemail for a couple of reasons. One, we want to support copying mail to multiple IMAP boxes, and two, IMAP was
broken because a STORE macro had been moved into this section of code.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78859 65c4cc65-6c06-0410-ace0-fbb531ad65f3
comment for this to be fixed for IMAP_STORAGE, as well. I left IMAP alone
since I know MarkM was working on this code right now for another reason.
This is broken even worse in trunk, but for a different reason. The fact
that the mailbox option supported multiple mailboxes is completely not obvious
from the code in the channel drivers. Anyway, I will fix that in another
commit ...
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
conference and options that use DTMF to activate various features. The problem
was that the BEGIN frame would be passed through, but the END frame would get
intercepted to activate a feature. Then, the other conference members would hear
DTMF for forever, which they didn't seem to like very much.
(closes issue #10400, reported by stevefeinstein, fixed by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: blitzrage
Patches:
bug0010194 uploaded by vovochka
Tested by: blitzrage
Fix a problem when you call Voicemail() with multiple mailboxes specified and
ODBC_STORAGE is in use. The audio part of the message was only given to the
first mailbox specified.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78101 65c4cc65-6c06-0410-ace0-fbb531ad65f3
thinking the 'n' option was in use.
(closes issue #10320, reported by jfitzgibbon, patched by me, tested by blitzrage and me)
Thank you blitzrage for all the testing you've done lately with queues! It's much appreciated!
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77854 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes an issue where if a caller calls into a queue where no one is logged in, they would wait forever even if a member
logged in at some point.
(closes issue #10346, reported by and tested by blitzrage, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77852 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: jtodd
Add SPEECH_DTMF_TERMINATOR variable so the user can specify the digit to terminate a DTMF string with. If none is specified then no terminator will be used.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77176 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This makes it so that the 'n' option for Queue() can act properly depending on which strategy is used. If the strategy is
roundrobin, rrmemory, or ringall, we want to ring each phone once before moving on in the dialplan. However, if any other strategy is
used, we will only ring one phone since it cannot be guaranteed that a different phone will ring on subsequent attempts to ring a phone.
As a side effect of this, the QUEUE_MEMBER_COUNT dialplan function now just reads the membercount variable instead of traversing through
the member list to figure out how many members there are.
Special thanks to blitzrage for helping to test this out.
(closes issue #10127, reported by bcnit, patched by me, tested by blitzrage)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@76801 65c4cc65-6c06-0410-ace0-fbb531ad65f3
depend upon the umask. Unfortunately, mkstemp() creates files with mode 0600,
regardless of the umask. This corrects that deficiency.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@76708 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Mark Michelson
Olle Johansson
Kevin P. Fleming
Jason Parker
Russell Bryant
Joshua Colp
Steve Murphy
Tilghman Lesher
Luigi Rizzo
BJ Weschke
TransNexus OSP Development
Jim Dixon
Dwayne M. Hubbard