aboutsummaryrefslogtreecommitdiffstats
path: root/apps
AgeCommit message (Collapse)AuthorFilesLines
2009-01-15Fix some crashes from bad datastore handling in app_queue.cmmichelson1-5/+10
* The queue_transfer_fixup function was searching for and removing the datastore from the incorrect channel, so this was fixed. * Most datastore operations regarding the queue_transfer datastore were being done without the channel locked, so proper channel locking was added, too. (closes issue #14086) Reported by: ZX81 Patches: 14086v2.patch uploaded by putnopvut (license 60) Tested by: ZX81, festr git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168628 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-14app_page was failing to compile in dev-mode on my gcc-4.2.4 system. This ↵murf1-1/+1
change gets rid of the warning. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168608 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-14Don't overflow when paging more than 128 extensionstwilson1-5/+19
The number of available slots for calls in app_page was hardcoded to 128. Proper bounds checking was not in place to enforce this limit, so if more than 128 extensions were passed to the Page() app, Asterisk would crash. This patch instead dynamically allocates memory for the ast_dial structures and removes the (non-functional) arbitrary limit. This issue would have special importance to anyone who is dynamically creating the argument passed to the Page application and allowing more than 128 extensions to be added by an outside user via some external interface. The patch posted by a_villacis was slightly modified for some coding guidelines and other cleanups. Thanks, a_villacis! (closes issue #14217) Reported by: a_villacis Patches: 20080912-asterisk-app_page-fix-buffer-overflow.patch uploaded by a (license 660) Tested by: otherwiseguy git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168593 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-13Revert unnecessary indications API change from rev 122314russell2-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168561 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-19This merges the masqpark branch into 1.4murf2-34/+25
These changes eliminate the need for (and use of) the KEEPALIVE return code in res_features.c; There are other places that use this result code for similar purposes at a higher level, these appear to be left alone in 1.4, but attacked in trunk. The reason these changes are being made in 1.4, is that parking ends a channel's life, in some situations, and the code in the bridge (and some other places), was not checking the result code properly, and dereferencing the channel pointer, which could lead to memory corruption and crashes. Calling the masq_park function eliminates this danger in higher levels. A series of previous commits have replaced some parking calls with masq_park, but this patch puts them ALL to rest, (except one, purposely left alone because a masquerade is done anyway), and gets rid of the code that tests the KEEPALIVE result, and the NOHANGUP_PEER result codes. While bug 13820 inspired this work, this patch does not solve all the problems mentioned there. I have tested this patch (again) to make sure I have not introduced regressions. Crashes that occurred when a parked party hung up while the parking party was listening to the numbers of the parking stall being assigned, is eliminated. These are the cases where parking code may be activated: 1. Feature one touch (eg. *3) 2. Feature blind xfer to parking lot (eg ##700) 3. Run Park() app from dialplan (eg sip xfer to 700) (eg. dahdi hookflash xfer to 700) 4. Run Park via manager. The interesting testing cases for parking are: I. A calls B, A parks B a. B hangs up while A is getting the numbers announced. b. B hangs up after A gets the announcement, but before the parking time expires c. B waits, time expires, A is redialed, A answers, B and A are connected, after which, B hangs up. d. C picks up B while still in parking lot. II. A calls B, B parks A a. A hangs up while B is getting the numbers announced. b. A hangs up after B gets the announcement, but before the parking time expires c. A waits, time expires, B is redialed, B answers, A and B are connected, after which, A hangs up. d. C picks up A while still in parking lot. Testing this throroughly involves acting all the permutations of I and II, in situations 1,2,3, and 4. Since I added a few more changes (ALL references to KEEPALIVE in the bridge code eliimated (I missed one earlier), I retested most of the above cases, and no crashes. H-extension weirdness. Current h-extension execution is not completely correct for several of the cases. For the case where A calls B, and A parks B, the 'h' exten is run on A's channel as soon as the park is accomplished. This is expected behavior. But when A calls B, and B parks A, this will be current behavior: After B parks A, B is hung up by the system, and the 'h' (hangup) exten gets run, but the channel mentioned will be a derivative of A's... Thus, if A is DAHDI/1, and B is DAHDI/2, the h-extension will be run on channel Parked/DAHDI/1-1<ZOMBIE>, and the start/answer/end info will be those relating to Channel A. And, in the case where A is reconnected to B after the park time expires, when both parties hang up after the joyful reunion, no h-exten will be run at all. In the case where C picks up A from the parking lot, when either A or C hang up, the h-exten will be run for the C channel. CDR's are a separate issue, and not addressed here. As to WHY this strange behavior occurs, the answer lies in the procedure followed to accomplish handing over the channel to the parking manager thread. This procedure is called masquerading. In the process, a duplicate copy of the channel is created, and most of the active data is given to the new copy. The original channel gets its name changed to XXX<ZOMBIE> and keeps the PBX information for the sake of the original thread (preserving its role as a call originator, if it had this role to begin with), while the new channel is without this info and becomes a call target (a "peer"). In this case, the parking lot manager thread is handed the new (masqueraded) channel. It will not run an h-exten on the channel if it hangs up while in the parking lot. The h exten will be run on the original channel instead, in the original thread, after the bridge completes. See bug 13820 for our intentions as to how to clean up the h exten behavior. Review: http://reviewboard.digium.com/r/29/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166093 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-19(closes issue #13480)jpeeler3-16/+4
Reported by: tzafrir Replace a bunch of if defined checks for Zaptel/DAHDI through several new defines in dahdi_compat.h. This removes a lot of code duplication. Example from bug: #ifdef HAVE_ZAPTEL fd = open("/dev/zap/pseudo", O_RDWR); #else fd = open("/dev/dahdi/pseudo", O_RDWR); #endif is replaced with: fd = open(DAHDI_FILE_PSEUDO, O_RDRW); git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165991 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-19Ensure that the chanspy datastore is fully initialized.russell1-1/+1
This patch resolved some random crash issues observed by a user on a BSD system (closes issue #14111) Reported by: ys Patches: app_chanspy.c.diff uploaded by ys (license 281) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165889 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-18Add mutexes around accesses to the IMAP library interface. This preventstilghman1-8/+42
certain crashes, especially when shared mailboxes are used. (closes issue #13653) Reported by: howardwilkinson Patches: asterisk-1.4.21.2-appvoicemail-sharedimap-lock.patch uploaded by howardwilkinson (license 590) Tested by: jpeeler git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165767 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-18Do not crash if we are not passed in a followme id.file1-6/+10
(closes issue #14106) Reported by: ys Patches: app_followme.c.2.diff uploaded by ys (license 281) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165537 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-17Reverse the fix from issue #6176 and add proper handling for that issue.tilghman1-19/+54
(Closes issue #13962, closes issue #13363) Fixed by myself (license 14) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165317 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-17Fix some memory leaks found while looking at how realtimemmichelson4-7/+15
configs are handled. Also cleaned up some coding guidelines violations in app_realtime.c, mostly related to spacing git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165255 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-16Do not dereference the channel if AST_PBX_KEEPALIVE has been returned.russell1-1/+1
This is a bug I noticed while looking at the code for app_macro. This return code means that another thread has assumed ownership of the channel and it can no longer be touched. (I hate this return code with a passion, by the way.) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@164876 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-15Can we try not to assign an unsigned int to -1?file1-1/+1
(closes issue #14074) Reported by: wetwired git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@164204 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-13Change the default calldurationlimit from the special value 0 to -1, so wetilghman1-3/+3
can better detect an exceptional case. This follows on to the changes made in revision 156386. Related to issue #13851. (closes issue #13974) Reported by: paradise Patches: 20081208__bug13974.diff.txt uploaded by Corydon76 (license 14) Tested by: file, blitzrage, ZX81 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@164082 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-11Revert this cast to long. Using time_t here causes build failures on a mmichelson1-2/+2
FreeBSD 32-bit build. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@163084 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-11Fix a potential crash due to unsafe datastore handling.mmichelson1-21/+21
This patch also contains a conversion from using long to time_t for representing times for a queue, as well as some whitespace fixes. (closes issue #14060) Reported by: nivek Patches: datastore_fixup.patch.corrected uploaded by nivek (license 636) with slight modification from me Tested by: nivek git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@163080 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-09Oops, should be "tz", not "zonetag".tilghman1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162463 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-09We appear to have documented tz= in the [general] section of voicemail.conf,tilghman1-0/+5
without actually having implemented it. Oops. (Reported by Olivier on the -users list) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162348 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-09Add 'down' as a valid state for directed call pickup. This creeps up when we ↵file1-1/+1
receive session progress when dialing a device and not ringing. (closes issue #14005) Reported by: ddl git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162341 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-09Fix an issue where callers on an incoming call on an SLA trunk would not ↵russell1-7/+27
hear ringback. We need to make sure that we don't start writing audio to the trunk channel until we're actually ready to answer it. Otherwise, the channel driver will treat it as inband progress, even though all they are getting is silence. (closes issue #12471) Reported by: mthomasslo git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162286 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-09Fix double declaration of 'x' on the PPC platform.file1-1/+0
(closes issue #14038) Reported by: ffloimair git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162273 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-09Allow DISA to handle extensions that start with #.russell1-2/+8
(closes issue #13330) Reported by: jcovert git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162014 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-03Some compilers warn on null format strings; some don't (caught by buildbot)tilghman1-6/+6
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@160770 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-02Ensure that Asterisk builds with --enable-dev-mode, even on the latest gcctilghman1-1/+3
and glibc. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@160207 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-25Add missing variable declaration in the PPC codetwilson1-0/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@159096 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-25System call ioperm is non-portable, so check for its existence in autoconf.tilghman1-0/+6
(Closes issue #13863) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@159025 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-21This change had somehow gotten reverted due to ammichelson1-2/+3
completely unrelated commit. Thanks to Theo Belder on the Asterisk-dev list for pointing this out. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@158306 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-20Make sure to set the hangup cause on the calling channel in the casemmichelson1-0/+3
that ast_call() fails. For incoming SIP channels, this was causing us to send a 603 instead of a 486 when the call-limit was reached on the destination channel. (closes issue #13867) Reported by: still_nsk Patches: 13867.diff uploaded by putnopvut (license 60) Tested by: blitzrage git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@158053 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-18(closes issue #13899)jpeeler1-1/+1
Reported by: akkornel This fix is the result of a bug fix in ast_app_separate_args r124395. If an argument does not exist it should always be set to a null string rather than a null pointer. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@157365 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-18Fix a crash in the end_bridge_callback of app_dial andmmichelson2-0/+11
app_followme which would occur at the end of an attended transfer. The error occurred because we initially stored a pointer to an ast_channel which then was hung up due to a masquerade. This commit adds a "fixup" callback to the bridge_config structure to allow for end_bridge_callback_data to be changed in the case that a new channel pointer is needed for the end_bridge_callback. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@157305 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-14If the prompt to reenter a voicemail password timed out, itmmichelson1-1/+1
resulted in the password not being saved, even if the input matched what you gave when first prompted to enter a new password. This is because the return value of ast_readstring was checked, but not checked properly. This bug was discovered by Jared Smith during an Asterisk training course. Thanks for reporting it! git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@156816 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-14ast_waitfordigit() requires that the channel be up, for no good logicaltilghman1-1/+5
reason. This prevents While/EndWhile from working within the "h" extension. Reported by: jgalarneau (for ABE C.2) Fixed by: me git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@156755 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-12When using call limits under 1 second, infinite call lengths are allowed,tilghman1-1/+4
instead. (closes issue #13851) Reported by: ruddy git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@156386 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-12If the SLA thread is not started, then reload causes a memory leak.tilghman1-0/+4
(closes issue #13889) Reported by: eliel Patches: app_meetme.c.patch uploaded by eliel (license 64) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@156294 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-12For whatever reason, gcc only warned me about the possible use of an ↵jpeeler1-1/+1
uninitialized variable when compiling 1.6.1. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@156289 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-12(closes issue #13173)jpeeler1-23/+149
Reported by: pep This change adds an announce_thread responsible for playing announcements to an existing conference. This allows all announcing to be immediately stopped if necessary but more importantly allows other threads that need to play something to not block. There are multiple benefits to this, but the actual bug is for solving the scenario for a channel to be unusable after hang up for the entire duration of the parting announcement. The parting announcement can be extremely long depending on what the user recorded upon joining the conference. Reviewed by Russell on Review Board: http://reviewboard.digium.com/r/25/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@156178 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-12When doing some tests, I was having a crash at the end of every callmmichelson1-0/+4
if an attended transfer occurred during the call. I traced the cause to the CDR on one of the channels being NULL. murf suggested a check in the end bridge callback to be sure the CDR is non-NULL before proceeding, so that's what I'm adding. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@156167 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-09Use static functions here instead of nested ones. This requires a smallseanbright2-42/+44
change to the ast_bridge_config struct as well. To understand the reason for this change, see the following post: http://gcc.gnu.org/ml/gcc-help/2008-11/msg00049.html git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@155553 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-03Attempting to expunge a mailbox when the mailstream is NULL will crash Asterisk.tilghman1-1/+1
(Closes issue #13829) Reported by: jaroth Patch by: me (modified jaroth's patch) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@154066 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-01fix a bunch of potential problems found by gcc 4.3.x, primarily bare strings ↵kpfleming6-12/+37
being passed to printf()-like functions and ignored results from read()/write() and friends git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@153337 f38db490-d61c-443f-a65b-d21fe96a405b
2008-10-31Add end_bridge_callback for app_follome and add AUTOLOOP flag to res_featurestwilson1-10/+24
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@153270 f38db490-d61c-443f-a65b-d21fe96a405b
2008-10-31Recent CDR fixes moved execution of the 'h' exten into the bridging code, so ↵twilson1-14/+25
variables that were set after ast_bridge_call was called would not show up in the 'h' exten. Added a callback function to handle setting variables, etc. from w/in the bridging code. Calls back into a nested function within the function calling ast_bridge_call (closes issue #13793) Reported by: greenfieldtech git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@153095 f38db490-d61c-443f-a65b-d21fe96a405b
2008-10-29A little documentation cross-ref between features andmurf2-13/+31
dial and queue... I wasted some time (stupidly) trying to get the one-touch parking stuff working, because it didn't occur to me that I had to also have the corresponding options in the dial command! Duh! (In all this time, I never set this up before!) So, to keep some poor fool from suffering the same fate, I made the features.conf.sample file mention the corresponding opts in dial/queue; and the docs for dial/app specifically mention the corresponding decls in the feature.conf file. I hope this doesn't spoil some vast, eternal plan... git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@152538 f38db490-d61c-443f-a65b-d21fe96a405b
2008-10-29The magic trick to avoid this crash is not tomurf2-26/+30
try to find the channel by name in the list, which is slow and resource consuming, but rather to pay attention to the result codes from the ast_bridge_call, to which I added the AST_PBX_NO_HANGUP_PEER_PARKED value, which now are returned when a channel is parked. If you get AST_PBX_KEEPALIVE, then don't touch the channel pointer. If you get AST_PBX_NO_HANGUP_PEER, or AST_PBX_NO_HANGUP_PEER_PARKED, then don't touch the peer pointer. Updated the several places where the results from a bridge were not being properly obeyed, and fixed some code I had introduced so that the results of the bridge were not overridden (in trunk). All the places that previously tested for AST_PBX_NO_HANGUP_PEER now have to check for both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED. I tested this against the 4 common parking scenarios: 1. A calls B; B answers; A parks B; B hangs up while A is getting the parking slot announcement, immediately after being put on hold. 2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but before the park times out. 3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold. 4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out. No crash. I also ran the scenarios above against valgrind, and accesses looked good. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@152535 f38db490-d61c-443f-a65b-d21fe96a405b
2008-10-28Quoting in the wrong directiontilghman1-1/+1
(Fixes AST-107) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@152463 f38db490-d61c-443f-a65b-d21fe96a405b
2008-10-28Reset all DIAL variables back to blank, in case Dial is called multiple timestilghman1-0/+7
per call (which could otherwise lead to inconsistent status reports). (closes issue #13216) Reported by: ruddy Patches: 20081014__bug13216.diff.txt uploaded by Corydon76 (license 14) Tested by: ruddy git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@152368 f38db490-d61c-443f-a65b-d21fe96a405b
2008-10-14Update the queue with the correct number of calls andmmichelson1-3/+8
whether the call was completed within the service level when a transfer takes place. This way, we do not "break" the leastrecent and fewestcalls strategies by not logging a call until after the transferred call has ended. (closes issue #13395) Reported by: Marquis Patches: app_queue.c.transfer.patch uploaded by Marquis (license 32) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@149200 f38db490-d61c-443f-a65b-d21fe96a405b
2008-10-14Check correct values in the return of ast_waitfor(); also, get rid of atilghman1-2/+4
possible memory leak. (closes issue #13658) Reported by: explidous Patch by: me git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@149061 f38db490-d61c-443f-a65b-d21fe96a405b
2008-10-14Some compilers warn, some don't. Fixing.tilghman1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@148987 f38db490-d61c-443f-a65b-d21fe96a405b
2008-10-14Ensure that mail headers are 7-bit clean, even when UTF-8 characters are usedtilghman1-24/+136
in headers like 'Subject' and 'To'. Closes AST-107. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@148916 f38db490-d61c-443f-a65b-d21fe96a405b