aboutsummaryrefslogtreecommitdiffstats
path: root/include/asterisk
AgeCommit message (Collapse)AuthorFilesLines
2008-05-29Oddly enough, all of the contents of audiohook.h were in there twice. I haverussell1-179/+0
removed the second copy. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@119076 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29Define also when not DEBUG_THREADStilghman1-0/+5
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@118954 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29Add some debugging code that ensures that when we do deadlock avoidance, wetilghman1-0/+32
don't lose the information about how a lock was originally acquired. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@118953 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-23Add format type checking for recently de-inlined functiontilghman1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@118055 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-23Don't declare a function that takes variable arguments as inline, because it'srussell1-14/+1
not valid, and on some compilers, will emit a warning. http://gcc.gnu.org/onlinedocs/gcc/Inline.html#Inline (closes issue #12289) Reported by: francesco_r Patches by Tilghman, final patch by me git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@118048 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-19The addition of usleep(2) within ast_assert requires the inclusion of the ↵tilghman1-0/+1
unistd.h header git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@117086 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-14Add ast_assert(), which can be used to handle fatal errors. It is only compiledrussell2-7/+27
in if dev-mode is enabled, and only aborts if DO_CRASH is defined. (inspired by issue #12650) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@116463 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-13A change to the way channel locks are handled when DEBUG_CHANNEL_LOCKS is ↵mmichelson1-3/+6
defined. After debugging a deadlock, it was noticed that when DEBUG_CHANNEL_LOCKS is enabled in menuselect, the actual origin of channel locks is obscured by the fact that all channel locks appear to happen in the function ast_channel_lock(). This code change redefines ast_channel_lock to be a macro which maps to __ast_channel_lock(), which then relays the proper file name, line number, and function name information to the core lock functions so that this information will be displayed in the case that there is some sort of locking error or core show locks is issued. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@116088 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-09Improve res_ninit and res_ndestroy autoconf logic on the Darwin platform.file1-0/+3
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115579 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-07Merged revisions 115511 via svnmerge from russell1-974/+0
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r115511 | russell | 2008-05-07 11:22:49 -0500 (Wed, 07 May 2008) | 3 lines Remove remnants of dlinkedlists. I didn't actually use them in the final version of my IAX2 improvements. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115512 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-05Make sure that either the main speex library contains preprocess functions ↵file1-0/+3
or that speexdsp does. If both fail then speex stuff can not be built. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115327 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-05Err, the documentation on the return value of ast_odbc_backslash_is_escape ↵tilghman1-1/+1
is exactly backwards. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115308 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-04For my next trick I will make these work with what our autoconf header file ↵file1-6/+6
gives us. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115279 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-02Add new "pri show version" command to show the libpri version for support ↵bbryant1-0/+3
reasons. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115257 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-02Clarify a comment that was, well, just wrong. It turns out thatmmichelson1-11/+5
ignoring the way that macros expand. Instead, I have clarified in the comment why the macro will work even if the scheduler id for the task to be deleted changes during the execution of the macro. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115196 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-01Change the comment of deprecated to an actual compiler deprecationtilghman1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115102 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-30Merge changes from team/russell/iax2_find_callno and iax2_find_callno_1.4russell1-0/+974
These changes address a critical performance issue introduced in the latest release. The fix for the latest security issue included a change that made Asterisk randomly choose call numbers to make them more difficult to guess by attackers. However, due to some inefficient (this is by far, an understatement) code, when Asterisk chose high call numbers, chan_iax2 became unusable after just a small number of calls. On a small embedded platform, it would not be able to handle a single call. On my Intel Core 2 Duo @ 2.33 GHz, I couldn't run more than about 16 IAX2 channels. Ouch. These changes address some performance issues of the find_callno() function that have bothered me for a very long time. On every incoming media frame, it iterated through every possible call number trying to find a matching active call. This involved a mutex lock and unlock for each call number checked. So, if the random call number chosen was 20000, then every media frame would cause 20000 locks and unlocks. Previously, this problem was not as obvious since Asterisk always chose the lowest call number it could. A second container for IAX2 pvt structs has been added. It is an astobj2 hash table. When we know the remote side's call number, the pvt goes into the hash table with a hash value of the remote side's call number. Then, lookups for incoming media frames are a very fast hash lookup instead of an absolutely insane array traversal. In a quick test, I was able to get more than 3600% more IAX2 channels on my machine with these changes. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114891 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-23Store the manager session ID explicitly as 4 byte ID instead of a ulong. Therussell1-2/+2
mansession_id cookie is coded to be limited to 8 characters of hex, and this could break logins from 64-bit machines in some cases. (inspired by AST-20) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114591 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-22Merge changes from team/russell/issue_9520russell1-4/+7
These changes make sure that the reference count for sip_peer objects properly reflects the fact that the peer is sitting in the scheduler for a scheduled callback for qualifying peers or for expiring registrations. Without this, it was possible for these callbacks to happen at the same time that the peer was being destroyed. This was especially likely to happen with realtime peers, and for people making use of the realtime prune CLI command. (closes issue #9520) Reported by: kryptolus Committed patch by me git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114522 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-17Add prototype for ast_dsp_frame_freed. I'm not sure how this wasmmichelson1-0/+13
compiling before... git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114211 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-17It was possible for a reference to a frame which was part of a freed DSP to ↵mmichelson1-0/+4
still be referenced, leading to memory corruption and eventual crashes. This code change ensures that the dsp is freed when we are finished with the frame. This change is very similar to a change Russell made with translators back a month or so ago. (closes issue #11999) Reported by: destiny6628 Patches: 11999.patch uploaded by putnopvut (license 60) Tested by: destiny6628, victoryure git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114207 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-10Fix 1.4 build when LOW_MEMORY is enabled.mmichelson1-0/+17
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114051 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-08If audio suddenly gets fed into one side of a channel after a lapse of ↵file1-0/+1
frames flush the other factory so that old audio does not remain in the factory causing the sync code to not execute. (closes issue #12296) Reported by: jvandal git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@113296 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-01Ensure that we do not exceed the hold's maximum size with a single frame.file1-1/+3
(closes issue #12047) Reported by: fabianoheringer Tested by: fabianoheringer git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@112125 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-27(closes issue #12302)murf1-0/+1
Reported by: pj Tested by: murf These changes will set a channel variable ~~EXTEN~~ just before generating code for a switch, with the value of ${EXTEN}. The exten is marked as having a switch, and ever after that, till the end of the exten, we substitute any ${EXTEN} with ${~~EXTEN~~} instead in application arguments; (and the ${EXTEN: also). The reason for this, is that because switches are coded using separate extensions to provide pattern matching, and jumping to/from these switch extensions messes up the ${EXTEN} value, which blows the minds of users. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@111341 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-25Add an option (transmit_silence) which transmits silence during both ↵file1-1/+1
Record() and DTMF generation. The reason this is an option is that in order to transmit silence we have to setup a translation path. This may not be needed/wanted in all cases. (closes issue #10058) Reported by: tracinet git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@110628 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-18Fix character string being treated ad format stringtwilson1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@109482 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-13Fix another issue that was causing crashes in chanspy. This introduces a newrussell1-0/+15
datastore callback, called chan_fixup(). The concept is exactly like the fixup callback that is used in the channel technology interface. This callback gets called when the owning channel changes due to a masquerade. Before this was introduced, if a masquerade happened on a channel being spyed on, the channel pointer in the datastore became invalid. (closes issue #12187) (reported by, and lots of testing from atis) (props to file for the help with ideas) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@108583 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-12Added a large comment before the AST_SCHED_DEL macro to explain its purpose ↵mmichelson1-2/+20
as well as when it is appropriate and when it is not appropriate to use it. I also removed the part of the debug message that mentions that this is probably a bug because there are some perfectly legitimate places where ast_sched_del may fail to delete an entry (e.g. when the scheduler callback manually reschedules with a new id instead of returning non-zero to tell the scheduler to reschedule with the same idea). I also raised the debug level of the debug message in AST_SCHED_DEL since it seems like it could come up quite frequently since the macro is probably being used in several places where it shouldn't be. Also removed the redundant line, file, and function information since that is provided by ast_log. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@108227 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-12Add a trigger mode that triggers on both read and write. The actual function ↵file1-0/+3
that returns the combined audio frame though will wait until both sides have fed in audio, or until one side stops (such as the case when you call Wait). (closes issue #11945) Reported by: xheliox git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@108083 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-11stop checking for mktime() in the configure script... we don't use it, and ↵kpfleming1-3/+0
the test is buggy under gcc 4.3 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@107461 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-10Move where unanswered CDRs are dropped to the CDR core, not everything uses ↵file1-1/+0
app_dial. (closes issue #11516) Reported by: ys Patches: branch_1.4_cdr.diff uploaded by ys (license 281) Tested by: anest, jcapp, dartvader git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@107016 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-07Change a warning message to a debug message. This is happening quite ↵russell1-1/+1
frequently, and it is not worth spamming users with these messages unless we are pretty confident that it should never happen. As it stands today, it _will_ and _does_ happen and until that gets cleaned up a reasonable amount on the development side, let's not spam the logs of everyone else. (closes issue #12154) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@106704 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-05Add a control frame to indicate the source of media has changed. Depending ↵file1-0/+2
on the underlying technology it may need to change some things. (closes issue #12148) Reported by: jcomellas git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@106235 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-05Correctly initialize retransid in SIP, and ensure that the warning when ↵tilghman1-1/+1
failing to delete a schedule entry can actually hit the log. (closes issue #12140) Reported by: slavon Patches: sch2.patch uploaded by slavon (license 288) (Patch slightly modified by me) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@106015 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-05Fix a bug that I just noticed in the RTP code. The calculation for setting therussell1-0/+11
len field in an ast_frame of audio was wrong when G.722 is in use. The len field represents the number of ms of audio that the frame contains. It would have set the value to be twice what it should be. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105932 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-04When a new source of audio comes in (such as music on hold) make sure the ↵file1-0/+2
marker bit gets set. (closes issue #10355) Reported by: wdecarne Patches: 10355.diff uploaded by file (license 11) (closes issue #11491) Reported by: kanderson git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105674 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-28Fix a bug in the lock tracking code that was discovered by mmichelson. The ↵russell1-9/+9
issue is that if the lock history array was full, then the functions to mark a lock as acquired or not would adjust the stats for whatever lock is at the end of the array, which may not be itself. So, do a sanity check to make sure that we're updating lock info for the proper lock. (This explains the bizarre stats on lock #63 in BE-396, thanks Mark!) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105116 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-26Merge changes from team/russell/smdi-1.4russell1-27/+95
This commit brings in a significant set of changes to the SMDI support in Asterisk. There were a number of bugs in the current implementation, most notably being that it was very likely on busy systems to pop off the wrong message from the SMDI message queue. So, this set of changes fixes the issues discovered as well as introducing some new ways to use the SMDI support which are required to avoid the bugs with grabbing the wrong message off of the queue. This code introduces a new interface to SMDI, with two dialplan functions. First, you get an SMDI message in the dialplan using SMDI_MSG_RETRIEVE() and then you access details in the message using the SMDI_MSG() function. A side benefit of this is that it now supports more than just chan_zap. For example, with this implementation, you can have some FXO lines being terminated on a SIP gateway, but the SMDI link in Asterisk. Another issue with the current implementation is that it is quite common that the station ID that comes in on the SMDI link is not necessarily the same as the Asterisk voicemail box. There are now additional directives in the smdi.conf configuration file which let you map SMDI station IDs to Asterisk voicemail boxes. Yet another issue with the current SMDI support was related to MWI reporting over the SMDI link. The current code could only report a MWI change when the change was made by someone calling into voicemail. If the change was made by some other entity (such as with IMAP storage, or with a web interface of some kind), then the MWI change would never be sent. The SMDI module can now poll for MWI changes if configured to do so. This work was inspired by and primarily done for the University of Pennsylvania. (also related to issue #9260) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104119 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-14Change to the configure logic regarding IMAP. Prior to this commit, if you ↵mmichelson1-0/+3
wished to configure Asterisk with IMAP support, you would use the --with-imap configure switch in one of the following two ways: --with-imap=/some/directory would look in the directory specified for a UW IMAP source installation --with-imap would assume that you had imap-2004g installed in .. relative to the Asterisk source With this set of changes the two above options still work the same, but there are two new behaviors, too. --with-imap=system will assume that you have -libc-client.so where you store your shared objects and will attempt to find c-client headers in your include path either in the imap or c-client directory. If either of the two original methods of specifying the imap option should fail, then the check for --with-imap =system will be performed in addition. It is only after this "system" check that failure can happen. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@103698 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-04Cross-platform fix: OS X now deprecates the use of the daemon(3) API.tilghman1-3/+3
(closes issue #11908) Reported by: oej Patches: 20080204__bug11908.diff.txt uploaded by Corydon76 (license 14) Tested by: Corydon76 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@102323 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-01Change detection of getifaddrs to use AST_C_COMPILE_CHECK, backported from ↵tilghman1-1/+4
trunk (as suggested by kpfleming) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@101894 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-01Compatibility fix for OpenWRT (reported by Brian Capouch via the mailing list)tilghman1-0/+3
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@101772 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-28Make some deadlock related fixes. These bugs were discovered and reportedrussell1-1/+4
internally at Digium by Steve Pitts. - Fix up chan_local to ensure that the channel lock is held before the local pvt lock. - Don't hold the channel lock when executing the timing function, as it can cause a deadlock when using chan_local. This actually changes the code back to be how it was before the change for issue #10765. But, I added some other locking that I think will prevent the problem reported there, as well. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@100581 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-27When deleting a task from the scheduler, ignoring the return value couldtilghman1-0/+10
possibly cause memory to be accessed after it is freed, which causes all sorts of random memory corruption. Instead, if a deletion fails, wait a bit and try again (noting that another thread could change our taskid value). (closes issue #11386) Reported by: flujan Patches: 20080124__bug11386.diff.txt uploaded by Corydon76 (license 14) Tested by: Corydon76, flujan, stuarth` git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@100465 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-24make these macros not assume that the only other field in the structure is ↵kpfleming1-2/+2
'argc'... this is true when someone uses AST_DECLARE_APP_ARGS, but it's perfectly reasonable to define your own structure as long as it has the right fields git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@100264 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-21Permit the user to specify number of seconds that a connection may remain idle,tilghman1-0/+1
which fixes a crash on reconnect with the MyODBC driver. (closes issue #11798) Reported by: Corydon76 Patches: 20080119__res_odbc__idlecheck.diff.txt uploaded by Corydon76 (license 14) Tested by: mvanbaak git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@99341 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-18Remove the __ in front of the unused variable. This causes some compilers to ↵file1-3/+2
freak out. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@99127 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-18Revert adding the packed attribute, as it really doesn't make sense why thatrussell1-1/+1
would do any good. Fix the real bug, which is to do the check to see if the frame came from a translator at the beginning of ast_frame_free(), instead of at the end. This ensures that it always gets checked, even if none of the parts of the frame are malloc'd, and also ensures that we aren't looking at free'd memory in the case that it is a malloc'd frame. (closes issue #11792, reported by explidous, patched by me) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@99081 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-18Since we're relying on the offset between the frame and the beginning of the ↵russell1-1/+1
translator pvt struct, set the packed attribute to make sure we get to the right place. (potential fix for issue #11792) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@99079 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-25 19:59:43 +0000