106 Commits (1.8)

Author	SHA1	Message	Date
Kinsey Moore	3e9a54d857	Allow Asterisk to compile under GCC 4.10 ... This resolves a large number of compiler warnings from GCC 4.10 which cause the build to fail under dev mode. The vast majority are signed/unsigned mismatches in printf-style format strings. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@413586 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	6a70940c54	core/loader: Don't call dlclose in a while loop ... For awhile now, we've noticed continuous integration builds hanging on CentOS 6 64-bit build agents. After resolving a number of problems with symbols, strange locks, and other shenanigans, the problem has persisted. In all cases, gdb shows the Asterisk process stuck in loader.c on one of the infinite while loops that calls dlclose repeatedly until success. The documentation of dlclose states that it returns 0 on success; any other value on error. It does not state that repeatedly calling it will eventually clear those errors. Most likely, the repeated calls to dlclose was to force a close by exhausting the references on the library; however, that will never succeed if: (a) There is some fundamental error at work in the loaded library that precludes unloading it (b) Some other loaded module is referencing a symbol in the currently loaded module This results in Asterisk sitting forever. Since we have matching pairs of dlopen/dlclose, this patch opts to only call dlclose once, and log out as an ERROR if dlclose fails to return success. If nothing else, this might help to determine why on the CentOS 6 64-bit build agent things are not closing successfully. Review: https://reviewboard.asterisk.org/r/2970 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@402287 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	f13bd7d90f	Fix memory leak while loading priority modules ... When we load a module with the LOAD_PRIORITY flag, we remove its entry from the load order list. Unfortunately, we don't free the memory associated with entry in the list. This patch corrects that and properly frees the memory for the module in the list. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@391489 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	091b93b98e	Fix potential double free when unloading a module. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@378092 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	f20a72153b	Add safety NULL pointer check in module user references. ... Made __ast_module_user_remove() check for NULL pointers. ........ Merged revision 375860 from C.3 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@375862 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Joshua Colp	6d3973330d	loader: Ensure dependent modules are properly initialized. ... If an Asterisk module specifies a dependency in ast_module_info.nonoptreq, it is possible for Asterisk to skip calling the modules's .load function. Asterisk was loading and linking the module via load_dynamic_module() but was not adding the module to the resource_heap. Therefore the module was not initialized based on it's priority along with the other modules in the heap. Now use load_resource() instead of load_dynamic_module() for non-optional requirement. This will add the module to the resource_heap so the module can be properly initialized in the correct order. This is required if there are any module global data structures initialized in the .load() callback for the module on platforms which do not support weak references. (issue ASTERISK-20439) Reported by: sruffell Patches: 0001-loader-Ensure-dependent-modules-are-properly-initial.patch uploaded by sruffell (license 5417) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373909 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	309d55382d	Add instrumentation to subsystem reloads ... When Asterisk is built with TEST_FRAMEWORK defined, Asterisk will now generate TestEvent AMI events on subsystem reloads such as cdr, dnsmgr, extconfig, etc. (issue PQ-1126) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371436 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	f817b8cdcd	Add module reload instrumentation for TEST_FRAMEWORK ... This adds AMI events for module reloads when Asterisk is built with TEST_FRAMEWORK enabled and corrects generation of the module load AMI event. (issue PQ-1126) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371393 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	af74988006	Add test instrumentation ... This adds test instrumentation for loading and unloading of modules and for certain actions in MeetMe to be used in the testsuite or any other consumer of AMI events. These will only be generated when Asterisk is built with TEST_FRAMEWORK enabled. (issue PQ-1131) (issue PQ-1133) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371201 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kevin P. Fleming	f83d1b98e8	Add support-level indications to many more source files. ... Since we now have tools that scan through the source tree looking for files with specific support levels, we need to ensure that every file that is a component of a 'core' or 'extended' module (or the main Asterisk binary) is explicitly marked with its support level. This patch adds support-level indications to many more source files in tree, but avoids adding them to third-party libraries that are included in the tree and to source files that don't end up involved in Asterisk itself. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@369001 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	0353a57671	Fix coverity UNUSED_VALUE findings in core support level files ... Most of these were just saving returned values without using them and in some cases the variable being saved to could be removed as well. (issue ASTERISK-19672) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@368738 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Terry Wilson	9a3c569772	Track module use count for res_calendar ... If the res_calendar module was followed immediately by one of the calendar tech modules and "core stop gracefully" was run, Asterisk would crash. This patch adds use count tracking for res_calendar so that it is unloaded after the tech modules when shutting down gracefully. It is now not possible to unload all the of the calendar modules via "module unload res_calednar.so", but it is still possible to unload them all via "module unload -h res_calendar.so". Review: https://reviewboard.asterisk.org/r/1752/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@356291 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Nicholson	de9e8e501e	Load the proper XML documentation when multiple modules document the same application. ... This patch adds an optional "module" attribute to the XML documentation spec that allows the documentation processor to match apps with identical names from different modules to their documentation. This patch also fixes a number of bugs with the documentation processor and should make it a little more efficient. Support for multiple languages has also been properly implemented. ASTERISK-18130 Review: https://reviewboard.asterisk.org/r/1485/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@340108 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Tilghman Lesher	7e3f95e00a	When optional_api is non-optional, force dependent modules to be loaded. ... (closes issue #17707) Reported by: ira Patches: 20100819__issue17707__asterisk1.8.diff.txt uploaded by tilghman (license 14) Tested by: tilghman Review: https://reviewboard.asterisk.org/r/876/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@284610 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Tilghman Lesher	b4e18d5660	Add load priority order, such that preload becomes unnecessary in most cases ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278132 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Tilghman Lesher	4c94d1ee23	Oops, merge reverted this fix. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276493 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Tilghman Lesher	832d1296c6	Remove the old stub files, preferring the optional_api method. ... (closes issue #17475) Reported by: tilghman Review: https://reviewboard.asterisk.org/r/695/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276490 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Kevin P. Fleming	8e7d01d484	Don't try to call an embedded module's backup_globals() function until ... after confirming it exists. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276441 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Matthew Nicholson	7f145eeb1b	Merged revisions 275182 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r275182 | mnicholson | 2010-07-09 13:23:23 -0500 (Fri, 09 Jul 2010) | 2 lines give a better error message when attempting to unload a module that is not loaded ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275186 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Matthew Nicholson	3fd53f575c	Merged revisions 275143 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r275143 | mnicholson | 2010-07-09 12:50:05 -0500 (Fri, 09 Jul 2010) | 2 lines don't unload modules that returned AST_MODULE_LOAD_DECLINE when they were loaded ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275144 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Mark Michelson	6bb45831eb	Fix transcode_via_sln option with SIP calls and improve PLC usage. ... From reviewboard: The problem here is a bit complex, so try to bear with me... It was noticed by a Digium customer that generic PLC (as configured in codecs.conf) did not appear to actually be having any sort of benefit when packet loss was introduced on an RTP stream. I reproduced this issue myself by streaming a file across an RTP stream and dropping approx. 5% of the RTP packets. I saw no real difference between when PLC was enabled or disabled when using wireshark to analyze the RTP streams. After analyzing what was going on, it became clear that one of the problems faced was that when running my tests, the translation paths were being set up in such a way that PLC could not possibly work as expected. To illustrate, if packets are lost on channel A's read stream, then we expect that PLC will be applied to channel B's write stream. The problem is that generic PLC can only be done when there is a translation path that moves from some codec to SLINEAR. When I would run my tests, I found that every single time, read and write translation paths would be set up on channel A instead of channel B. There appeared to be no real way to predict which channel the translation paths would be set up on. This is where Kevin swooped in to let me know about the transcode_via_sln option in asterisk.conf. It is supposed to work by placing a read translation path on both channels from the channel's rawreadformat to SLINEAR. It also will place a write translation path on both channels from SLINEAR to the channel's rawwriteformat. Using this option allows one to predictably set up translation paths on all channels. There are two problems with this, though. First and foremost, the transcode_via_sln option did not appear to be working properly when I was placing a SIP call between two endpoints which did not share any common formats. Second, even if this option were to work, for PLC to be applied, there had to be a write translation path that would go from some format to SLINEAR. It would not work properly if the starting format of translation was SLINEAR. The one-line change presented in this review request in chan_sip.c fixed the first issue for me. The problem was that in sip_request_call, the jointcapability of the outbound channel was being set to the format passed to sip_request_call. This is nativeformats of the inbound channel. Because of this, when ast_channel_make_compatible was called by app_dial, both channels already had compatibly read and write formats. Thus, no translation path was set up at the time. My change is to set the jointcapability of the sip_pvt created during sip_request_call to the intersection of the inbound channel's nativeformats and the configured peer capability that we determined during the earlier call to create_addr. Doing this got the translation paths set up as expected when using transcode_via_sln. The changes presented in channel.c fixed the second issue for me. First and foremost, when Asterisk is started, we'll read codecs.conf to see the value of the genericplc option. If this option is set, and ast_write is called for a frame with no data, then we will attempt to fill in the missing samples for the frame. The implementation uses a channel datastore for maintaining the PLC state and for creating a buffer to store PLC samples in. Even when we receive a frame with data, we'll call plc_rx so that the PLC state will have knowledge of the previous voice frame, which it can use as a basis for when it comes time to actually do a PLC fill-in. So, reviewers, now I ask for your help. First off, there's the one line change in chan_sip that I have put in. Is it right? By my logic it seems correct, but I'm sure someone can tell me why it is not going to work. This is probably the change I'm least concerned about, though. What concerns me much more is the set of changes in channel.c. First off, am I even doing it right? When I run tests, I can clearly see that when PLC is activated, I see a significant increase in RTP traffic where I would expect it to be. However, in my humble opinion, the audio sounds kind of crappy whenever the PLC fill-in is done. It sounds worse to me than when no PLC is used at all. I need someone to review the logic I have used to be sure that I'm not misusing anything. As far as I can see my pointer arithmetic is correct, and my use of AST_FRIENDLY_OFFSET should be correct as well, but I'm sure someone can point out somewhere where I've done something incorrectly. As I was writing this review request up, I decided to give the code a test run under valgrind, and I find that for some reason, calls to plc_rx are causing some invalid reads. Apparently I'm reading past the end of a buffer somehow. I'll have to dig around a bit to see why that is the case. If it's obvious to someone reviewing, speak up! Finally, I have one other proposal that is not reflected in my code review. Since without transcode_via_sln set, one cannot predict or control where a translation path will be up, it seems to me that the current practice of using PLC only when transcoding to SLINEAR is not useful. I recommend that once it has been determined that the method used in this code review is correct and works as expected, then the code in translate.c that invokes PLC should be removed. Review: https://reviewboard.asterisk.org/r/622/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264452 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Paul Belanger	7d53dc86d6	Notify CLI when modules is loaded / unloaded ... (closes issue #17308) Reported by: pabelanger Patches: cli.modules.patch uploaded by pabelanger (license 224) Tested by: pabelanger, russell git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@262800 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Tilghman Lesher	bbb5acc65e	RTP documentation states that you can pass NULL as the module, so make sure that's really the case. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@247125 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Jeff Peeler	a170cd28e0	Add new option to asterisk.conf (lockconfdir) to protect conf dir during reloads ... (closes issue #16358) Reported by: raarts Patches: lockconfdir.diff uploaded by raarts (license 937) modified by me git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@243551 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Olle Johansson	ebc3aff1c3	Fixing trunk in a way so that it compiles again. ... Thanks, Philippe :-) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@229871 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Olle Johansson	75c015bfff	Add the capability to require a module to be loaded, or else Asterisk exits. ... Review: https://reviewboard.asterisk.org/r/426/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@229819 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Tilghman Lesher	c0b3c923a4	Fix various problems detected with Valgrind. ... * chan_console accessed pvts after deallocation. * cdr_mysql stored a pointer that was freed by realloc() * The module loader did not check usecount on shutdown, which led to chan_iax2 reading a timer that was already unloaded. * The event subsystem sometimes creates an event with no IEs. Due to a corner condition, the code would read beyond the memory boundary. * res_pktccops did not correctly check whether its monitor thread was started. (closes issue #16062) Reported by: alexanderheinz Patches: 20091109__issue16062.diff.txt uploaded by tilghman (license 14) Tested by: tilghman git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@228798 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Terry Wilson	ad37760473	Make LOAD_ORDER actually work ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@213450 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Brooks	d81d6d3415	Fixing typos. Replaces "recieved" with "received" and "initilize" with "initialize" ... (closes issue #15571) Reported by: alecdavis git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@209098 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	0264eef115	Merge the new Channel Event Logging (CEL) subsystem. ... CEL is the new system for logging channel events. This was inspired after facing many problems trying to represent what is possible to happen to a call in Asterisk using CDR records. For more information on CEL, see the built in HTML or PDF documentation generated from the files in doc/tex/. Many thanks to Steve Murphy (murf) and Brian Degenhardt (bmd) for their hard work developing this code. Also, thanks to Matt Nicholson (mnicholson) and Sean Bright (seanbright) for their assistance in the final push to get this code ready for Asterisk trunk. Review: https://reviewboard.asterisk.org/r/239/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203638 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	87c8658912	attempting to load running modules ... Modules placed in the priority heap for loading were not properly removed from the linked list. This resulted in some modules attempting to load twice. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@202410 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Kevin P. Fleming	82fb56886e	More 'static' qualifiers on module global variables. ... The 'pglobal' tool is quite handy indeed :-) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200620 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	d532cbcd8a	module load priority ... This patch adds the option to give a module a load priority. The value represents the order in which a module's load() function is initialized. The lower the value, the higher the priority. The value is only checked if the AST_MODFLAG_LOAD_ORDER flag is set. If the AST_MODFLAG_LOAD_ORDER flag is not set, the value will never be read and the module will be given the lowest possible priority on load. Since some modules are reliant on a timing interface, the timing modules have been given a high load priorty. (closes issue #15191) Reported by: alecdavis Tested by: dvossel Review: https://reviewboard.asterisk.org/r/262/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199743 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Sean Bright	befad10893	Merged revisions 199022 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r199022 | seanbright | 2009-06-04 10:14:57 -0400 (Thu, 04 Jun 2009) | 40 lines Safely handle AMI connections/reload requests that occur during startup. During asterisk startup, a lock on the list of modules is obtained by the primary thread while each module is initialized. Issue 13778 pointed out a problem with this approach, however. Because the AMI is loaded before other modules, it is possible for a module reload to be issued by a connected client (via Action: Command), causing a deadlock. The resolution for 13778 was to move initialization of the manager to happen after the other modules had already been lodaded. While this fixed this particular issue, it caused a problem for users (like FreePBX) who call AMI scripts via an #exec in a configuration file (See issue 15189). The solution I have come up with is to defer any reload requests that come in until after the server is fully booted. When a call comes in to ast_module_reload (from wherever) before we are fully booted, the request is added to a queue of pending requests. Once we are done booting up, we then execute these deferred requests in turn. Note that I have tried to make this a bit more intelligent in that it will not queue up more than 1 request for the same module to be reloaded, and if a general reload request comes in ('module reload') the queue is flushed and we only issue a single deferred reload for the entire system. As for how this will impact existing installations - Before 13778, a reload issued before module initialization was completed would result in a deadlock. After 13778, you simply couldn't connect to the manager during startup (which causes problems with #exec-that-calls-AMI configuration files). I believe this is a good general purpose solution that won't negatively impact existing installations. (closes issue #15189) (closes issue #13778) Reported by: p_lindheimer Patches: 06032009_15189_deferred_reloads.diff uploaded by seanbright (license 71) Tested by: p_lindheimer, seanbright Review: https://reviewboard.asterisk.org/r/272/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199051 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Kevin P. Fleming	e6b2e9a750	Const-ify the world (or at least a good part of it) ... This patch adds 'const' tags to a number of Asterisk APIs where they are appropriate (where the API already demanded that the function argument not be modified, but the compiler was not informed of that fact). The list includes: - CLI command handlers - CLI command handler arguments - AGI command handlers - AGI command handler arguments - Dialplan application handler arguments - Speech engine API function arguments In addition, various file-scope and function-scope constant arrays got 'const' and/or 'static' qualifiers where they were missing. Review: https://reviewboard.asterisk.org/r/251/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196072 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Joshua Colp	63de834395	Merge in the RTP engine API. ... This API provides a generic way for multiple RTP stacks to be integrated into Asterisk. Right now there is only one present, res_rtp_asterisk, which is the existing Asterisk RTP stack. Functionality wise this commit performs the same as previously. API documentation can be viewed in the rtp_engine.h header file. Review: http://reviewboard.digium.com/r/209/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186078 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	4210f17abb	Merged revisions 183241 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r183241 | russell | 2009-03-19 12:52:52 -0500 (Thu, 19 Mar 2009) | 2 lines Remove the use of RTLD_NOLOAD, as it is not behaving like expected. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183242 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	4ec301360c	Merge a large set of updates to the Asterisk indications API. ... 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	16 years ago
Tilghman Lesher	08af5bb312	Create a new config file status, CONFIG_STATUS_FILEINVALID for differentiating ... when a file is invalid from when a file is missing. This is most important when we have two configuration files. Consider the following example: Old system: sip.conf users.conf Old result New result ======== ========== ========== ========== Missing Missing SIP doesn't load SIP doesn't load Missing OK SIP doesn't load SIP doesn't load Missing Invalid SIP doesn't load SIP doesn't load OK Missing SIP loads SIP loads OK OK SIP loads SIP loads OK Invalid SIP loads incompletely SIP doesn't load Invalid Missing SIP doesn't load SIP doesn't load Invalid OK SIP doesn't load SIP doesn't load Invalid Invalid SIP doesn't load SIP doesn't load So in the case when users.conf doesn't load because there's a typo that disrupts the syntax, we may only partially load users, instead of failing with an error, which may cause some calls not to get processed. Worse yet, the old system would do this with no indication that anything was even wrong. (closes issue #10690) Reported by: dtyoo Patches: 20080716__bug10690.diff.txt uploaded by Corydon76 (license 14) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142992 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	6291cd19bf	remove remaining Zaptel references in various places ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134086 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	9a08061ea3	Merged revisions 131921 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r131921 | kpfleming | 2008-07-18 11:15:41 -0500 (Fri, 18 Jul 2008) | 2 lines remove the dlfcn compatibility stuff, because no platforms that Asterisk currently runs on it use it, and it doesn't build anyway ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@131923 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Jeff Peeler	ef3b214728	Goodbye Zaptel, hello DAHDI. Removes Zaptel driver support with DAHDI. Configuration file and dialplan backwards compatability has been put in place where appropiate. Release announcement to follow. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122234 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	90d75af346	Conditionally load the AGI command gosub, depending on whether or not res_agi ... has been loaded, fix a return value in the loader, and ensure that the help workhorse header does not print on load. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@120602 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	ef4eff9a9b	Add the "config reload <conffile>" command, which allows you to tell Asterisk ... to reload any file that references a given configuration file. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111012 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	10609251f9	Revert several changes from revision 102525, as the changes were not ... compatible, and, in fact, introduced regressions. (Closes issue #12190) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@107960 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	8a411ccf83	Create a centralized configuration option for silencethreshold ... (closes issue #11236) Reported by: philipps Patches: 20080218__bug11236.diff.txt uploaded by Corydon76 (license 14) Tested by: philipps git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@106072 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	cfc1df4c1a	Whitespace changes only ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105840 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	b868d44342	Merged revisions 104596 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r104596 | file | 2008-02-27 13:07:33 -0400 (Wed, 27 Feb 2008) | 4 lines Use the lock (which already existed, it just wasn't used) on the updaters list to protect the contents instead of the overall module list lock. (closes issue #12080) Reported by: ChaseVenters ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104597 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	ee5e39e04b	Add a log message that appears when you try to unload a module that isn't loaded. ... (closes issue #12033) Reported by: jamesgolovich Patches: asterisk-loader.diff.txt uploaded by jamesgolovich (license 176) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103828 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Russell Bryant	75fd299f1b	Merged revisions 103728 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r103728 | russell | 2008-02-15 13:50:11 -0600 (Fri, 15 Feb 2008) | 4 lines In the case that you try to directly reload a module has returned AST_MODULE_LOAD_DECLINE, log a message indicating that the module is not fully initialized and must be initialized using "module load". ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103729 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago