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
