https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r184078 | mmichelson | 2009-03-24 17:34:45 -0500 (Tue, 24 Mar 2009) | 9 lines
Change NULL pointer check to be ast_strlen_zero.
The 'digit' variable is guaranteed to be non-NULL, so the if
statement could never evaluate true. Changing to ast_strlen_zero
makes the logic correct.
This was found while reviewing ast_channel_ao2 code review.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@184079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183386 | dvossel | 2009-03-19 14:40:07 -0500 (Thu, 19 Mar 2009) | 6 lines
Cleaning up a few things in detect disconnect patch
Initialized ast_call_feature in detect_disconnect to avoid accessing uninitialized memory. Cleaned up /param tags in features.h. No longer send dynamic features in ast_feature_detect.
issue #11583
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For every attempt that app_queue made to place an outbound call to a queue member,
we would allocate a queue_end_bridge structure. When the bridge for the call had
completed, we would free the structure. Unfortunately not all call attempts actually
end up bridged to a member, so we need to be more selective of when to allocate
the structure. With this change, the allocation occurs in an area where we can
guarantee that the call will be bridged.
(closes issue #14680)
Reported by: caspy
Patches:
14680.patch uploaded by mmichelson (license 60)
Tested by: caspy
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183244 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r182810 | russell | 2009-03-17 21:09:13 -0500 (Tue, 17 Mar 2009) | 44 lines
Fix cases where the internal poll() was not being used when it needed to be.
We have seen a number of problems caused by poll() not working properly on
Mac OSX. If you search around, you'll find a number of references to using
select() instead of poll() to work around these issues. In Asterisk, we've
had poll.c which implements poll() using select() internally. However, we
were still getting reports of problems.
vadim investigated a bit and realized that at least on his system, even
though we were compiling in poll.o, the system poll() was still being used.
So, the primary purpose of this patch is to ensure that we're using the
internal poll() when we want it to be used.
The changes are:
1) Remove logic for when internal poll should be used from the Makefile.
Instead, put it in the configure script. The logic in the configure
script is the same as it was in the Makefile. Ideally, we would have
a functionality test for the problem, but that's not actually possible,
since we would have to be able to run an application on the _target_
system to test poll() behavior.
2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT
is not defined.
3) Change uses of poll() throughout the source tree to ast_poll(). I feel
that it is good practice to give the API call a new name when we are
changing its behavior and not using the system version directly in all cases.
So, normally, ast_poll() is just redefined to poll(). On systems where
AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll().
4) Change poll() in main/poll.c to be ast_internal_poll().
It's worth noting that any code that still uses poll() directly will work fine
(if they worked fine before). So, for example, out of tree modules that are
using poll() will not stop working or anything. However, for modules to work
properly on Mac OSX, ast_poll() needs to be used.
(closes issue #13404)
Reported by: agalbraith
Tested by: russell, vadim
http://reviewboard.digium.com/r/198/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182847 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The D() option in app_dial is only able to send DTMF after the call has been answered. A progress option has been added to D() to allow DTMF to be sent upon receiving PROGRESS. This allows DTMF to be sent before the call is answered.
(closes issue #12123)
Reported by: VoipForces
Patches:
app_dial.c_patch_trunk_valid uploaded by VoipForces (license 419)
dtmf_progress.patch uploaded by dvossel (license 671)
Tested by: VoipForces, dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182596 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If trying to dial a non-existent queue, there would
be a segfault when attempting to access q->weight, even
though q was NULL. This problem was introduced during
the queue-reset merge and thus only affects trunk.
(closes issue #14643)
Reported by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181244 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r180464 | mmichelson | 2009-03-05 17:26:11 -0600 (Thu, 05 Mar 2009) | 16 lines
[IMAP] Fix message retrieval issues when identical mailbox names were defined in separate contexts.
There was a fix put in a while back so that an X-Asterisk-VM-Context message header was
added to stored IMAP voicemails. This would allow for us to differentiate if the same
mailbox name was used in multiple contexts. The problem still left was that not all places
where messages were retrieved actually attempted to use this header for information when
retrieving messages. This commit fixes that so that MWI and message retrieval from VoiceMailMain
work as expected.
(closes issue #13853)
Reported by: vicks1
Patches:
13853_v2.patch uploaded by mmichelson (license 60)
Tested by: lmadsen
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180465 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r180380 | mmichelson | 2009-03-05 12:58:48 -0600 (Thu, 05 Mar 2009) | 25 lines
Fix broken mailbox parsing when searchcontexts option is enabled.
When using the searchcontexts option in voicemail.conf, the code
made the assumption that all mailbox names defined were unique across
all contexts. However, the code did nothing to actually enforce this
assumption, nor did it do anything to alert a user that he may have
created an ambiguity in his voicemail.conf file by defining the same
mailbox name in multiple contexts.
With this change, we now will issue a nice long warning if searchcontexts
is on and we encounter the same mailbox name in multiple contexts and ignore
any duplicates after the first box. Whether searchcontexts is enabled or not,
if we come across a duplicate mailbox in the same context, then we will issue
a warning and ignore the duplicated mailbox. I have also added a small note
to voicemail.conf.sample in the explanation for searchcontexts explaining
that you cannot define the same mailbox in multiple contexts if you have
enabled the option.
(closes issue #14599)
Reported by: lmadsen
Patches:
14599.patch uploaded by mmichelson (license 60) (with slight modification)
Tested by: lmadsen
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180383 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit brings in the bridging core, bridging technologies,
and the ConfBridge application.
For usage information on the ConfBridge application please see
the output of "core show application ConfBridge" from the CLI.
For API documentation please see the doxygen page describing the
architecture and the documentation for each API call.
Review: http://reviewboard.digium.com/r/93/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180369 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In app.c, ast_app_getdata is called to stream the prompts and receive DTMF input. If ast_app_getdata() receives an empty string caused by the user inputing the end of string character, in this case '#', it should break from the prompt loop and return to app_read, but instead it cycles through all the prompts. I've added a return value for this special case in ast_readstring() which uses an enum I've delcared in apps.h. This enum is now used as a return value for ast_app_getdata().
(closes issue #14279)
Reported by: Marquis
Patches:
fix_app_read.patch uploaded by Marquis (license 32)
read-ampersanmd.patch2 uploaded by dvossel (license 671)
Tested by: Marquis, dvossel
Review: http://reviewboard.digium.com/r/177/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180032 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r180006 | mmichelson | 2009-03-03 16:48:18 -0600 (Tue, 03 Mar 2009) | 17 lines
Clarify some documentation of queues.conf.sample
It had always been possible to explicitly specify a "blank"
value for a sound file in queues.conf and have no sound played
back. The problem with this is that it would result in some ugly
CLI warnings from file.c.
This commit introduces a check when playing a file in app_queue
to see if the name of the file is zero-length and return early if
that is the case. Also, the ability to specify the blank sound
files in queues.conf is now mentioned more clearly in queues.conf.sample
(closes issue #14227)
Reported by: caspy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When app_meetme finds a realtime conference, it doesn't get the filename and fileformat correctly when 'r' is set. Now app_meetme first checks to see if fileformat and filename are declared in the db, if they're not it checks the .conf file, if its not declared there either it then uses defaults.
(closes issue #14545)
Reported by: dalbaech
Patches:
app_meetme-realtime5.patch uploaded by dvossel (license 671)
Realtime_Conference_Record_workaround.txt uploaded by dalbaech (license 705)
Tested by: dvossel, dalbaech
Review: http://reviewboard.digium.com/r/180/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179972 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179532 | russell | 2009-03-02 17:34:13 -0600 (Mon, 02 Mar 2009) | 40 lines
Move ast_waitfor() down to avoid the results of the API call becoming stale.
This call to ast_waitfor() was being done way too soon in this section of code.
Specifically, there was code in between the call to waitfor and the code that
uses the result that puts the channel in autoservice. By putting the channel
in autoservice, the previous results of ast_waitfor() become meaningless,
as the autoservice thread will do it's own ast_waitfor() and ast_read()
on the channel.
So, when we came back out of autoservice and eventually hit the block of code
that calls ast_read() on the channel, there may not actually be any input on
the channel available. Even though the previous call to ast_waitfor() in
app_meetme said there was input, the autoservice thread has since serviced
the channel for some period of time.
This bug manifested itself while dvossel was doing some testing of MeetMe in
Asterisk trunk. He was using the timerfd timing module. When the code hit
ast_read() erroneously, it determined that it must have been called because of
input on the timer fd, as chan->fdno was set to AST_TIMING_FD, since that was
the cause of the last legitimate call to ast_read() done by autoservice.
In this test, an IAX2 channel was calling into the MeetMe conference. It was
_much_ more likely to be seen with an IAX2 channel because of the way audio
is handled. Every audio frame that comes in results in a call to
ast_queue_frame(), which then uses ast_timer_enable_continuous() to notify
the channel thread that a frame is waiting to be handled. So, the chances
of ast_waitfor() indicating that a channel needs servicing due to a timer
event on an IAX2 event is very high.
Finally, it is interesting to note that if a different timing interface was
being used, this bug would probably not be noticed. When ast_read() is called
and erroneously thinks that there is a timer event to handle, it calls the
ast_timer_ack() function. The pthread and dahdi timing modules handle the
ack() function being called when there is no event by simply ignoring it.
In the case of the timerfd module, it results in a read() on the timer fd
that will block forever, as there is no data to read. This caused Asterisk
to lock up very quickly.
Thanks to dvossel and mmichelson for the fun debugging session. :-)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179533 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to spandsp-0.0.6pre4 the t30_stats_t structure used a pages_transferred
integer to indicate the number of pages transferred (so far) during the fax
session. The spandsp-0.0.6pre4 release removed the pages_transferred integer
and replaced it with two different integers - pages_tx and pages_rx. This
revision uses the new integers for spandsp-0.0.6pre4 while maintaining backwards
compatibility for previous spandsp releases.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177699 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Enabling this option by default proved to be a bad idea, as the talker detection
is not very reliable. So, make it optional again, and off by default.
(issue #13801)
Reported by: justdave
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177101 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch includes a number of changes to the indications API. The primary
motivation for this work was to improve stability. The object management
in this API was significantly flawed, and a number of trivial situations could
cause crashes.
The changes included are:
1) Remove the module res_indications. This included the critical functionality
that actually loaded the indications configuration. I have seen many people
have Asterisk problems because they accidentally did not have an
indications.conf present and loaded. Now, this code is in the core,
and Asterisk will fail to start without indications configuration.
There was one part of res_indications, the dialplan applications, which did
belong in a module, and have been moved to a new module, app_playtones.
2) Object management has been significantly changed. Tone zones are now
managed using astobj2, and it is no longer possible to crash Asterisk by
issuing a reload that destroys tone zones while they are in use.
3) The API documentation has been filled out.
4) The API has been updated to follow our naming conventions.
5) Various bits of code throughout the tree have been updated to account
for the API update.
6) Configuration parsing has been mostly re-written.
7) "Code cleanup"
The code is from svn/asterisk/team/russell/indications/.
Review: http://reviewboard.digium.com/r/149/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176627 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem here is that the hint processing code was subscribed to the wrong
event type. So, it started processing state for a hint too soon, before the
device state cache had been updated.
Also, fix a similar bug in app_queue, as it was also subscribed to the wrong
event type.
(closes issue #14461)
Reported by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176249 | mmichelson | 2009-02-16 15:34:27 -0600 (Mon, 16 Feb 2009) | 14 lines
Open the DAHDI pseudo device and set it to be nonblocking atomically
Apparently on FreeBSD, attempting to set the O_NONBLOCKING flag separately
from opening the file was causing an "inappropriate ioctl for device" error.
While I cannot fathom why this would be happening, I certainly am not opposed
to making the code a bit more compact/efficient if it also fixes a bug.
(closes issue #14482)
Reported by: ys
Patches:
meetme.patch uploaded by ys (license 281)
Tested by: ys
........
r176252 | mmichelson | 2009-02-16 15:39:21 -0600 (Mon, 16 Feb 2009) | 3 lines
Remove unused variable and make dev-mode compilation happy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176253 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From a user point-of-view, this adds new CLI commands and Manager Actions to
better facilitate the reloading of queues and the resetting of their statistics.
The new CLI commands are the "queue reload" and "queue reset stats" commands.
The new manager actions are the QueueReload and QueueReset commands.
Review: http://reviewboard.digium.com/r/115
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175663 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r175590 | mmichelson | 2009-02-13 13:47:48 -0600 (Fri, 13 Feb 2009) | 16 lines
Fix a potential crash situation when using IMAP voicemail
If calling into VoiceMailMain when using IMAP storage, it was
possible to crash Asterisk by hanging up the phone when prompted
for a voicemail mailbox. This patch fixes the issue.
While it may appear that this patch is superficial, it allows code
execution to continue to the failure case just below the IMAP_STORAGE
code block where this patch has been applied
(closes issue #14473)
Reported by: dwpaul
Patches:
voicemail_imap_crash_no_mailbox.patch uploaded by dwpaul (license 689)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175591 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If someone has configured the queue to play an position or holdtime
announcement, then it is odd and potentially unexpected to hear a
"Thank you for your patience" sound when no position or holdtime
was actually announced.
This fixes the announcement so that the "thanks" sound is only played
in the case that a position or holdtime was actually announced.
There is a way that the "thank you" sound can be played without a
position or holdtime, and that is to set announce-frequency to a value
but keep announce-position and announce-holdtime both turned off.
(closes issue #14227)
Reported by: caspy
Patches:
14227_v3.patch uploaded by putnopvut (license 60)
Tested by: caspy
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The 'd' option would not work for channel types which use RTP to transport
DTMF digits. The only way to allow for this to work was to answer the channel
if we saw that this option was enabled.
I realized that this may cause issues with CDRs, specifically with giving false
dispositions and answer times. I therefore modified ast_answer to take another
parameter which would tell if the CDR should be marked answered.
I also extended this to the Answer application so that the channel may be answered
but not CDRified if desired.
I also modified app_dictate and app_waitforsilence to only answer the channel if it
is not already up, to help not allow for faulty CDR answer times.
All of these changes are going into Asterisk trunk. For 1.6.0 and 1.6.1, however, all
the changes except for the change to the Answer application will go in since we do
not introduce new features into stable branches
(closes issue #14164)
Reported by: DennisD
Patches:
14164.patch uploaded by putnopvut (license 60)
Tested by: putnopvut
Review: http://reviewboard.digium.com/r/145
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using the 'g' or 'e' options, the stack allocations that
were used could cause a stack overflow if a spyer stayed on the
line long enough without actually successfully spying on anyone.
The problem has been corrected by using static buffers and copying
the contents of the appropriate strings into them instead of using
functions like alloca or ast_strdupa
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174805 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ignore_hangup, run_dead, and noanswer flags were never initilized to zero causing hangups to never be issued. If the external script expects to be notified of a hangup and never receives one, it runs indefinitely.
(closes issue #14251)
Reported by: chris-mac
Tested by: dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174325 65c4cc65-6c06-0410-ace0-fbb531ad65f3
