for the string to be copied into. This resulted in parse_request reading invalid
memory beyond the end of the string, and in some cases led to crashes. Thanks
to falves11 for providing the valgrind output which led to the closure of this issue.
(closes issue #12284)
Reported by: falves11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111662 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r111341 | murf | 2008-03-26 21:21:05 -0600 (Wed, 26 Mar 2008) | 15 lines
(closes issue #12302)
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: https://origsvn.digium.com/svn/asterisk/trunk@111360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Per comments from dimas:
1. The code now generates DTMF_BEGIN frames in addition to DTMF_END ones.
2. "quelching" rewritten - now each detector (MF/DTMF/generic tone) may mark fragment of a frame for suppression (squelching, muting) with a call to mute_fragment. Actual muting happens only once at the very end of ast_dsp_process where all marked fragments are zeroed. This way every detector sees original data in the frame without any piece of a frame being zeroed by a detector which was run before.
3. DTMF detector tries to "mute" one block before and one block after the block where actual tone was detected. Muting of previois block is something new for this patch. Obviously this operation is not always possible - if current frame does not contain data for previous block - it is too late. But at least we make our best.
Muting of next block was already done by the old code but it only affects part of the next block which is in the frame being processed. New code keeps this information in state structures so it will mute proper number of samples in the next frame(s) too.
4. Removed ast_dsp_digitdetect and ast_dsp_getdigits APIs because these are not used.
5. DSP API extended a bit - ast_dsp_was_muted() function added which returns true if DSP code was muting any fragment in the last frame. chan_zap uses this function to decide it needs to turn on confmute on the channel.
This is to replace AST_FRAME_DTMF 'm'/'u' (mute/unmute) functionality.
(closes issue #11968)
Reported by: dimas
Patches:
v2-11968-dsp.patch uploaded by dimas (license 88)
v4-11968-zap.patch uploaded by dimas (license 88)
Tested by: dimas, qwell
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111022 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110628 | file | 2008-03-25 11:37:35 -0300 (Tue, 25 Mar 2008) | 4 lines
Add an option (transmit_silence) which transmits silence during both 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: https://origsvn.digium.com/svn/asterisk/trunk@110629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
actual problems, per se. I also added format attributes to any printf wrapper functions I found that didn't have them. -Wsecurity and -Wmissing-format-attribute added to --enable-dev-mode.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109447 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r109309 | murf | 2008-03-18 00:37:15 -0600 (Tue, 18 Mar 2008) | 17 lines
(closes issue #11903)
Reported by: atis
Many thanks to atis for spotting this problem and reporting it.
The fix was to straighten out how items are placed on and removed
from the file stack. Regressions as well as the provided test case
helped to straighten out all code paths. valgrind was used to make
sure all memory allocated was freed.
Sorry for not solving this earlier. I got distracted.
Added the ntest23 regression test, which is mainly a copy of ntest22,
but with a few juicy errors thrown in, to replicate the kind of
error that atis spotted.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109357 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This does introduce a dependency on the GMime library for handling HTTP POSTs, but it is available in most distros.
If the library is present, then the compile flag for ENABLE_UPLOADS is enabled by default in menuselect.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109229 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: mvanbaak
Tested by: murf, mvanbaak
Due to a bug that occurred when merge_contexts_and_delete scanned the "old" or existing contexts, and found a context
that doesn't exist in the new set, yet owned by a different registrar. The context is created in the new set, with the
old registrar, and and all the priorities and extens that have a different registrar are copied into it. But, not the
includes, ignorepats, and switches. I added code to do this immediately after the context is created.
This still leaves a logical hole in the code. If you define a context in two places, (eg. in extensions.conf and also
in extensions.ael), and they both have includes, but different in composition, no new context will be generated, and
therefore the 'old' includes, switches, and ignorepats will not be copied. I'd have added code to simply add any non-duplicates
into the 'new' context that had a different registrar, but there is one big complication: includes, and switches are definitely
order dependent. (ignorepats I'm not sure about). And we'll have to develop some sort of policy about how we
merge order dependent lists, especially if the intersection of the two sets is empty. (in other words, they do not have any
elements in common). Do the new go first, or the old? I've elected to punt this issue until a user complains. Hopefully,
this is pretty rare thing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108583 | russell | 2008-03-13 16:38:16 -0500 (Thu, 13 Mar 2008) | 11 lines
Fix another issue that was causing crashes in chanspy. This introduces a new
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: https://origsvn.digium.com/svn/asterisk/trunk@108584 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108227 | mmichelson | 2008-03-12 16:16:28 -0500 (Wed, 12 Mar 2008) | 12 lines
Added a large comment before the AST_SCHED_DEL macro to explain its purpose 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: https://origsvn.digium.com/svn/asterisk/trunk@108238 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108083 | file | 2008-03-12 15:26:37 -0300 (Wed, 12 Mar 2008) | 4 lines
Add a trigger mode that triggers on both read and write. The actual function 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: https://origsvn.digium.com/svn/asterisk/trunk@108084 65c4cc65-6c06-0410-ace0-fbb531ad65f3
caching would not work properly for users.conf and any other file read from
more than one place. I needed to add the filename which requested the config
file to get it to work properly.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@107791 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: rizzo
Tested by: murf
Proposal of the changes to be made, and then an announcement of how they were accomplished:
http://lists.digium.com/pipermail/asterisk-dev/2008-February/032065.html
and:
http://lists.digium.com/pipermail/asterisk-dev/2008-March/032124.html
Here is a recap, file by file, of what I have done:
pbx/pbx_config.c
pbx/pbx_ael.c
All funcs that were passed a ptr to the context list, now will ALSO be passed a hashtab ptr to the same set.
Why? because (for the time being), the dialplan is stored in both, to facilitate a quick, low-cost move to
hash-tables to speed up dialplan processing. If it was deemed necessary to pass the context LIST, well, it
is just as necessary to have the TABLE available. This is because the list/table in question might not be
the global one, but temporary ones we would use to stage the dialplan on, and then swap into the global
position when things are ready.
We now have one external function for apps to use, "ast_context_find_or_create()" instead of the pre-existing
"find" and "create", as all existing usages used both in tandem anyway.
pbx_config, and pbx_ael, will stage the reloaded dialplan into local lists and tables, and
then call merge_contexts_and_delete, which will merge (now) existing contexts and
priorities from other registrars into this local set by copying them. Then, merge_contexts_and_delete will
lock down the contexts, swap the lists and tables, and unlock (real quick), and then
destroy the old dialplan.
chan_sip.c
chan_iax.c
chan_skinny.c
All the channel drivers that would add regcontexts now use the ast_context_find_or_create now.
chan_sip also includes a small fix to get rid of warnings about removing priorities that never got entered.
apps/app_meetme.c
apps/app_dial.c
apps/app_queue.c
All the apps that added a context/exten/priority were also modified to use ast_context_find_or_create instead.
include/asterisk/pbx.h
ast_context_create() is removed. Find_or_create_ is the new method.
ast_context_find_or_create() interface gets the hashtab added.
ast_merge_contexts_and_delete() gets the local hashtab arg added.
ast_wrlock_contexts_version() is added so you can detect if someone else got a writelock between your readlocking and writelocking.
ast_hashtab_compare_contexts was made public for use in pbx_config/pbx_ael
ast_hashtab_hash_contexts was in like fashion make public.
include/asterisk/pval.h
ast_compile_ael2() interface changed to include the local hashtab table ptr.
main/features.c
For the sake of the parking context, we use ast_context_find_or_create().
main/pbx.c
I changed all the "tree" names to "table" instead. That's because the original
implementation was based on binary trees. (had a free library). Then I moved
to hashtabs. Now, the names move forward too.
refcount field added to contexts, so you can keep track of how many modules
wanted this context to exist.
Some log messages that are warnings were inflated from LOG_NOTICE to LOG_WARNING.
Added some calls to ast_verb(3,...) for debug messages
Lots of little mods to ast_context_remove_extension2, which is now excersized in ways
it was not previously; one definite bug fixed.
find_or_create was upgraded to handle both local lists/tables as well as the globals.
context_merge() was added to do the per-context merging of the old/present contexts/extens/prios into the new/proposed local list/tables
ast_merge_contexts_and_delete() was heavily modified.
ast_add_extension2() was also upgraded to handle changes.
the context_destroy() code was re-engineered to handle the new way of doing things,
by exten/prio instead of by context.
res/ael/pval.c
res/ael/ael.tab.c
res/ael/ael.tab.h
res/ael/ael.y
res/ael/ael_lex.c
res/ael/ael.flex
utils/ael_main.c
utils/extconf.c
utils/conf2ael.c
utils/Makefile
Had to change the interface to ast_compile_ael2(), to include the hashtab ptr.
This ended up involving several external apps. The main gotcha was I had to
include lock.h and hashtab.h in several places.
As a side note, I tested this stuff pretty thoroughly, I replicated the problems
originally reported by Luigi, and made triply sure that reloads worked, and everything
worked thru "stop gracefully". I found a and fixed a few bugs as I was merging into
trunk, that did not appear in my tests of bug6002.
How's this for verbose commit messages?
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@106757 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r106704 | russell | 2008-03-07 11:16:58 -0600 (Fri, 07 Mar 2008) | 8 lines
Change a warning message to a debug message. This is happening quite 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: https://origsvn.digium.com/svn/asterisk/trunk@106707 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r106015 | tilghman | 2008-03-05 09:17:16 -0600 (Wed, 05 Mar 2008) | 7 lines
Correctly initialize retransid in SIP, and ensure that the warning when 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: https://origsvn.digium.com/svn/asterisk/trunk@106036 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105932 | russell | 2008-03-04 19:52:18 -0600 (Tue, 04 Mar 2008) | 5 lines
Fix a bug that I just noticed in the RTP code. The calculation for setting the
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: https://origsvn.digium.com/svn/asterisk/trunk@105933 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105674 | file | 2008-03-04 14:05:28 -0400 (Tue, 04 Mar 2008) | 8 lines
When a new source of audio comes in (such as music on hold) make sure the 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: https://origsvn.digium.com/svn/asterisk/trunk@105675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
LIST instead of an RWLIST. The way this list works makes it such that
a RWLIST provides no additional benefit. Also, a mutex is needed for
use with the thread condition.
Merged revisions 105563 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105563 | russell | 2008-03-03 09:50:43 -0600 (Mon, 03 Mar 2008) | 24 lines
Merge in some changes from team/russell/autoservice-nochans-1.4
These changes fix up some dubious code that I came across while auditing what
happens in the autoservice thread when there are no channels currently in
autoservice.
1) Change it so that autoservice thread doesn't keep looping around calling
ast_waitfor_n() on 0 channels twice a second. Instead, use a thread condition
so that the thread properly goes to sleep and does not wake up until a
channel is put into autoservice.
This actually fixes an interesting bug, as well. If the autoservice thread
is already running (almost always is the case), then when the thread goes
from having 0 channels to have 1 channel to autoservice, that channel would
have to wait for up to 1/2 of a second to have the first frame read from it.
2) Fix up the code in ast_waitfor_nandfds() for when it gets called with no
channels and no fds to poll() on, such as was the case with the previous code
for the autoservice thread. In this case, the code would call alloca(0), and
pass the result as the first argument to poll(). In this case, the 2nd
argument to poll() specified that there were no fds, so this invalid pointer
shouldn't actually get dereferenced, but, this code makes it explicit and
ensures the pointers are NULL unless we have valid data to put there.
(related to issue #12116)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105564 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105116 | russell | 2008-02-28 16:23:05 -0600 (Thu, 28 Feb 2008) | 8 lines
Fix a bug in the lock tracking code that was discovered by mmichelson. The 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: https://origsvn.digium.com/svn/asterisk/trunk@105144 65c4cc65-6c06-0410-ace0-fbb531ad65f3
automatically generated file like it used to be. This still needs to be there
for modules that have to check it to compile against multiple asterisk versions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104244 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104119 | russell | 2008-02-25 18:25:29 -0600 (Mon, 25 Feb 2008) | 33 lines
Merge changes from team/russell/smdi-1.4
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: https://origsvn.digium.com/svn/asterisk/trunk@104120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1024 was used instead of 128 when using AES from OpenSSL. Many thanks
to d1mas for figuring this one out!
(closes issue #11946)
Reported by: bbhoss
Patches:
v1-11946.patch uploaded by dimas (license 88)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103739 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also removes second check for awk, which causes Solaris to find an incompatible version of awk.
(closes issue #11829)
Reported by: snuffy
Patches:
bug-11829.diff uploaded by snuffy (license 35)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103694 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added ability to retrieve list of categories in a config file.
Added ability to retrieve the content of a particular category.
Added ability to empty a context.
Created new action to create a new file.
Updated delete action to allow deletion by line number with respect to category.
Added new action insert to add new variable to category at specified line.
Updated action newcat to allow new category to be inserted in file above another existing category.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r100581 | russell | 2008-01-28 11:15:41 -0600 (Mon, 28 Jan 2008) | 9 lines
Make some deadlock related fixes. These bugs were discovered and reported
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: https://origsvn.digium.com/svn/asterisk/trunk@100582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
that was just merged from 1.4, so this is a changeover to those APIs to use the
macro versions, so that we properly detect errors from ast_sched_del, instead
of simply ignoring the return values.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r100465 | tilghman | 2008-01-27 15:59:53 -0600 (Sun, 27 Jan 2008) | 11 lines
When deleting a task from the scheduler, ignoring the return value could
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: https://origsvn.digium.com/svn/asterisk/trunk@100488 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r100264 | kpfleming | 2008-01-24 15:57:41 -0600 (Thu, 24 Jan 2008) | 2 lines
make these macros not assume that the only other field in the structure is '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: https://origsvn.digium.com/svn/asterisk/trunk@100265 65c4cc65-6c06-0410-ace0-fbb531ad65f3
as a channel variable BRIDGEPVTCALLID
This is important for call tracing in log files and CDRs, so that
the SIP callID can be traced along servers.
The CHANNEL dialplan function won't work here, since the outbound
channel is gone when we need the Call-ID.
Other channel drivers may now implement the same function :-),
but this patch only supports chan_sip.so.
Inspired by (issue #11816)
Reported by: ctooley
Patch by oej
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99644 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r99341 | tilghman | 2008-01-21 12:11:07 -0600 (Mon, 21 Jan 2008) | 8 lines
Permit the user to specify number of seconds that a connection may remain idle,
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: https://origsvn.digium.com/svn/asterisk/trunk@99350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This set of changes introduces TCP and TLS support for chan_sip. There are various
new options in configs/sip.conf.sample that are used to enable these features. Also,
there is a document, doc/siptls.txt that describes some things in more detail.
This code was implemented by Brett Bryant and James Golovich. It was reviewed
by Joshua Colp and myself. A number of other people participated in the testing
of this code, but since it was done outside of the bug tracker, I do not have their
names. If you were one of them, thanks a lot for the help!
(closes issue #4903, but with completely different code that what exists there.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99085 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r99081 | russell | 2008-01-18 15:37:21 -0600 (Fri, 18 Jan 2008) | 9 lines
Revert adding the packed attribute, as it really doesn't make sense why that
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: https://origsvn.digium.com/svn/asterisk/trunk@99082 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r99079 | russell | 2008-01-18 15:22:21 -0600 (Fri, 18 Jan 2008) | 4 lines
Since we're relying on the offset between the frame and the beginning of the translator
pvt struct, set the packed attribute to make sure we get to the right place.
(potential fix for issue #11792)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r99004 | russell | 2008-01-17 16:37:22 -0600 (Thu, 17 Jan 2008) | 10 lines
Have IAX2 optimize the codec translation path just like chan_sip does it. If
the caller's codec is in our codec list, move it to the top to avoid transcoding.
(closes issue #10500)
Reported by: stevedavies
Patches:
iax-prefer-current-codec.patch uploaded by stevedavies (license 184)
iax-prefer-current-codec.1.4.patch uploaded by stevedavies (license 184)
Tested by: stevedavies, pj, sheldonh
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r98943 | russell | 2008-01-15 17:26:52 -0600 (Tue, 15 Jan 2008) | 25 lines
Commit a fix for some memory access errors pointed out by the valgrind2.txt
output on issue #11698.
The issue here is that it is possible for an instance of a translator to get
destroyed while the frame allocated as a part of the translator is still being
processed. Specifically, this is possible anywhere between a call to ast_read()
and ast_frame_free(), which is _a lot_ of places in the code. The reason this
happens is that the channel might get masqueraded during this time. During a
masquerade, existing translation paths get destroyed.
So, this patch fixes the issue in an API and ABI compatible way. (This one is
for you, paravoid!)
It changes an int in ast_frame to be used as flag bits. The 1 bit is still used
to indicate that the frame contains timing information. Also, a second flag has
been added to indicate that the frame came from a translator. When a frame with
this flag gets released and has this flag, a function is called in translate.c to
let it know that this frame is doing being processed. At this point, the flag gets
cleared. Also, if the translator was requested to be destroyed while its internal
frame still had this flag set, its destruction has been deffered until it finds out
that the frame is no longer being processed.
Admittedly, this feels like a hack. But, it does fix the issue, and I was not able
to think of a better solution ...
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) Add the Dialplan class, for NewExten and VarSet events, which should cut
down on the volume of traffic in the Call class.
2) Permit some commands to be run from multiple classes, such as allowing
DBGet to be run from either the System or the Reporting class.
3) Heavily document each class in the sample config, as there were several
that made no sense to be in the write= line, and two that made no sense to be
in the read= line (since they controlled no permissions there).
(Closes issue #10386)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@97651 65c4cc65-6c06-0410-ace0-fbb531ad65f3
based on configuration templates that use Asterisk dialplan function and
variable substitution. It should be possible to create phone profiles and
templates that work for the majority of phones provisioned over http. It
is currently only intended to provision a single user account per phone.
An example profile and set of templates for Polycom phones is provided.
NOTE: Polycom firmware is not included, but should be placed in
AST_DATA_DIR/phoneprov/configs to match up with the included templates.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@97634 65c4cc65-6c06-0410-ace0-fbb531ad65f3
revision changed, every module that used the version was getting rebuilt after
every svn update. This severly annoyed me pretty quickly, so I have improved
the situation.
Now, instead of generating version.h, main/version.c is generated. version.c
includes the version information, as well as a couple of API calls for modules
to retrieve the version. So now, only version.c will get rebuilt, and the main
asterisk binary relinked, which is must faster than rebuilding http.c, manager.c,
asterisk.c, relinking the asterisk binary, chan_sip.c, func_version.c, res_agi ...
The only minor change in behavior here is that the version information reported by
chan_sip, for example, is the version of the Asterisk core, and not necessarily the
Asterisk version that the chan_sip module came from.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@96717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
finish implementation of check for Zaptel HWGAIN support
add check for Zaptel ECHOCANCEL_PARAMS support
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@95937 65c4cc65-6c06-0410-ace0-fbb531ad65f3
which make maintaining this file very error prone.
This commit merges the embedded and !embedded versions,
and fixes the C++ version. Eventually we should move to
a single version of the macro.
Too bad C++ doesn't like the C-style struct initializers
.foo = some_value
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@95771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
iconv dependency for func_iconv.
This fixes some build issues on CYGWIN and FreeBSD and probably
other platforms where libiconv is not there by default
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@95624 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r94828 | russell | 2007-12-27 08:33:21 -0600 (Thu, 27 Dec 2007) | 9 lines
Change ast_translator_best_choice() to only pay attention to audio formats.
This fixes a problem where Asterisk claims that a translation path can not be
found for channels involving video.
(closes issue #11638)
Reported by: cwhuang
Tested by: cwhuang
Patch suggested by cwhuang, with some additional changes by me.
........
r94829 | russell | 2007-12-27 08:44:29 -0600 (Thu, 27 Dec 2007) | 2 lines
Use the constant that I really meant to use here ...
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@94830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
see description in config.h .
They are a variant of the set of macros i used in chan_oss.c,
structured in a way to be more robust to the presence of
spurious ';' - basically, they define wrappers for 'do {'
and '} while (0)', plus some helper functions to deal with simple
cases such as ast_copy_string, ast_malloc, strtoul, ast_true ...
The prefix (CV_ as 'Config Variable') tries to be easy to remember
and has been chosen to not conflict with other existing macros in the tree.
For the time being, I have only updated the three source files in the
tree that used the old M_* macros. Hopefully, more files will be
converted.
NOTE:
I understand that inventing my own dialect of C is generally wrong;
however, the lack of adequate support in the language encourages
lazy programming practices (such as ignoring errors, bounds, etc.)
and this increases the chance of vulnerability in the code, especially
because we are parsing user input here.
Hopefully, these macros and the use of ast_parse_arg (in config.h)
should encourage the programmer to write more robust code.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@94191 65c4cc65-6c06-0410-ace0-fbb531ad65f3
so that paths and filename are writable by asterisk.c without
causing segfaults.
This involves defining the variables as const char *,
and having them point to as static, writable buffer
defined in asterisk.c
On passing, fix some errors in using these variables
in some files in utils/ , and in res/snmp/agent.c
which was redefining a variable without using paths.h
(not applicable to 1.4)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@94168 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and likely in other places too.
This is quite useful when placing mail/html stuff in config files.
/*!
\brief Convert some C escape sequences (\b\f\n\r\t) into the
equivalent characters.
\brief s The string to be converted (will be modified).
\return The converted string.
*/
char *ast_unescape_c(char *s);
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
NETSMP and GTK (GTK is not used thoug).
AST_EXT_TOOL_CHECK() could be used for checking curl status
as well, perhaps with a small addition because we currently seem
to require a curl version greater than X.Y.Z
Add a NETSMP_INCLUDE entry in makeopts.in
We don't have yet any macros for using pkg-config to check
for a specific package (right now there is only gtk2+
in the category).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93898 65c4cc65-6c06-0410-ace0-fbb531ad65f3
modified.
This requires casting the strings in asterisk.c when writing to
them, so we do it through a macro to do it consistently.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93603 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r93336 | tilghman | 2007-12-17 15:12:42 -0600 (Mon, 17 Dec 2007) | 6 lines
Today is tomorrow's yesterday, and yesterday's tomorrow is today, and
tomorrow's tomorrow is the day after tomorrow, so who cares if you
recycle anyway?
If this confuses you, that's nothing compared to what this fixes. ;-)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93337 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r93180 | kpfleming | 2007-12-16 22:44:51 -0800 (Sun, 16 Dec 2007) | 23 lines
In http://lists.digium.com/pipermail/asterisk-dev/2007-December/031145.html,
rizzo brought up some issues related to the way that the metadata required
for menuselect and the rest of the build system is extracted from the source
files. Since I had a few hours to kill on an airplane today, I decided to
improve this situation... so now the system caches the extracted metadata
and uses it to build the menuselect 'tree' as much as it can. The result
of this is that when a single source file is changed, only the metadata for
that file needs to be extracted again, and the rest is used from the cache
files. I also reduced the number of forked processes required to do the
metadata extraction; it was actually possible to do most of what we needed
in the Makefiles themselves without using any shell scripts at all! On my
laptop, these changes resulted in an 80% decrease in the time required
for the 'menuselect.makeopts' automatic check to occur after editing a single
source file.
While doing this work I also cleaned up a few minor things in the Makefiles,
adding a check for 'awk' to the configure script and changed all remaining
places we use 'grep' or 'awk' to use the ones found by the configure script,
and changed the 'prep_tarball' script to build the menuselect metadata so
that tarballs of Asterisk will include it and won't require the user to
wait while it is extracted after unpacking.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93184 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Refer to the proper documentation
- Implement separate signalling/media QoS/CoS in many channels using RTP
- Improve warnings and verbose messages
- Deprecate some old settings
Minor modifications by me, a big effort from IgorG.
Thanks!
Reported by: IgorG
Patches:
qoscleanup-89394-4-trunk.patch uploaded by IgorG (license 20)
Tested by: IgorG
(closes issue #11145)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93163 65c4cc65-6c06-0410-ace0-fbb531ad65f3
equivalent to the check done by ast_verb, I wrote a macro, VERBOSITY_LEVEL, which does this
check. I did a quick look in the source and used this macro in some places where option_verbose
was used.
I also converted some verbose messages in logger.c to use ast_verb instead of ast_verbose.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r92875 | mmichelson | 2007-12-13 19:24:06 -0600 (Thu, 13 Dec 2007) | 7 lines
When compiling with DETECT_DEADLOCKS, don't spam the CLI with messages
about possible deadlocks. Instead just print the intended single message every
five seconds.
(closes issue 11537, reported and patched by dimas)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@92876 65c4cc65-6c06-0410-ace0-fbb531ad65f3
structures missing. Patched configure to check for this stuff and
put a #ifdef around the offending code in chan_zap. Thanks to file
for overseeing this.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@92422 65c4cc65-6c06-0410-ace0-fbb531ad65f3
get_unaligned functions as const
* In event.c, use get_unaligned_uint32() in a couple of places to fix issues on
architectures that don't allow unaligned access
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@92305 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91828 | russell | 2007-12-07 15:17:24 -0600 (Fri, 07 Dec 2007) | 6 lines
Fix another bug in the DEBUG_THREADS code. The ast_mutex_init() function had
the mutex attribute object marked as static. This means that multiple threads
initializing locks at the same time could step on each other and end up with
improperly initialized locks.
(found when tracking down locking issues related to issue #11080)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91826 | russell | 2007-12-07 15:11:08 -0600 (Fri, 07 Dec 2007) | 6 lines
I love fixing lock related errors in the lock debugging code. That's about as
ironic as it gets in Asterisk programming land. Anyway, I spotted this bug while
trying to track down why systems are locking up and acting weird in issue #11080.
The mutex attribute object was marked as static in this function when it should
not have been.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91827 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91070 | russell | 2007-12-04 18:35:31 -0600 (Tue, 04 Dec 2007) | 11 lines
Fix some crashes in chan_iax2 that were reported as happening on Mac systems.
It turns out that the problem was the Mac version of the ast_atomic_fetchadd_int()
function. The Mac atomic add function returns the _new_ value, while this function
is supposed to return the old value. So, the crashes happened on unreferencing
objects. If the reference count was decreased to 1, ao2_ref() thought that it
had been decreased to zero, and called the destructor. However, there was still
an outstanding reference around.
(closes issue #11176)
(closes issue #11289)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91114 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This introduces two new options for zapata.conf: mwimonitor and mwimonitornotify.
The mwimonitor option enables MWI monitoring. When the MWI state on a line changes,
then the script specified by mwimonitornotify will be executed for custom handling
of the state change, similar to the externnotify option of voicemail.conf.
Also, when the MWI state on an FXO line changes, an internal Asterisk event is
generated to indicate the new state of the associated mailbox. That may, any
module that cares about MWI information will get notified and can handle it
just as if app_voicemail had sent this notification.
(BE-253, original patch from markster, with some minor modifications by me to
add comments, documentation, and internal event support)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This works in much the same way as the automonitor, except that instead of using the monitor
app, it uses the mixmonitor app. By providing an 'x' or 'X' as a dial or queue option, a DTMF
sequence may be entered (as defined in features.conf) to start the one-touch mixmonitor.
This patch also introduces some new API calls to the audiohooks code for searching for an audiohook
by type and for searching for a running audiohook by type.
Big thanks to joetester for writing the initial patch, testing it and patiently waiting for it to
be committed.
(closes issue #10185, reported and patched by xmarksthespot)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90388 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90348 | russell | 2007-11-30 13:26:04 -0600 (Fri, 30 Nov 2007) | 8 lines
Change the behavior of ao2_link(). Previously, in inherited a reference.
Now, it automatically increases the reference count to reflect the reference
that is now held by the container.
This was done to be more consistent with ao2_unlink(), which automatically
releases the reference held by the container. It also makes it so it is
no longer possible for a pointer to be invalid after ao2_link() returns.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90351 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90145 | russell | 2007-11-28 18:20:34 -0600 (Wed, 28 Nov 2007) | 5 lines
This set of changes is to make some callerID handling thread-safe.
The ast_set_callerid() function needed to lock the channel. Also, the handlers
for the CALLERID() dialplan function needed to lock the channel when reading
or writing callerid values directly on the channel structure.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90146 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was mostly to note whether a channel needed to be locked or not before
calling these functions. However, I added some other things, too.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90139 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89893 | russell | 2007-11-27 18:20:13 -0600 (Tue, 27 Nov 2007) | 4 lines
- update documentation for some of the goto functions to note that they
handle locking the channel as needed
- update ast_explicit_goto() to lock the channel as needed
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89915 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also by accident fixed a bad typo by a previous committer, which actually made video calls
not work fully...
Merged revisions 89630 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89630 | oej | 2007-11-27 16:23:17 +0100 (Tis, 27 Nov 2007) | 12 lines
If we get a codec offer using a well-known payload type, but using it for another
codec that we don't know, Asterisk did not remove that codec from the list.
With this patch, we remove the codec from audio and video rtp objects and
deny it ever existed. Thanks to lasse for testing.
(closes issue #11376)
Reported by: lasse
Patches:
bug11376.txt uploaded by oej (license 306)
Tested by: lasse
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89698 65c4cc65-6c06-0410-ace0-fbb531ad65f3
except with an additional boolean arg.
A hack such as:
foo ? S_OR(bar, "baz") : "baz"
becomes:
S_COR(foo, bar, "baz")
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89622 | murf | 2007-11-26 23:24:02 -0700 (Mon, 26 Nov 2007) | 1 line
closes issue #11379; OK, this is an attempt to make both sides happy. To the cdr.conf file, I added the option 'unanswered', which defaults to 'no'. In this mode, you will see a cdr for a call, whether it was answered or not. The disposition will be NO ANSWER or ANSWERED, as appropriate. The src is as you'd expect, the destination channel will be one of the channels from the Dial() call, usually the last in the list if more than one chan was specified. With unanswered set to 'yes', you will still see this cdr entry in both cases. But in the case where the dial timed out, you will also see a cdr for each line attempted, marked NO ANSWER, with no destination channel name. The new option defaults to 'no', so you don't see the pesky extra cdr's by default, and you will not see the irritating 'not posted' messages.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89559 | tilghman | 2007-11-25 11:17:10 -0600 (Sun, 25 Nov 2007) | 14 lines
We previously attempted to use the ESCAPE clause to set the escape delimiter to
a backslash. Unfortunately, this does not universally work on all databases,
since on databases which natively use the backslash as a delimiter, the
backslash itself needs to be delimited, but on other databases that have no
delimiter, backslashing the backslash causes an error.
So the only solution that I can come up with is to create an option in res_odbc
that explicitly specifies whether or not backslash is a native delimiter. If
it is, we use it natively; if not, we use the ESCAPE clause to make it one.
Reported by: elguero
Patch by: tilghman
(Closes issue #11364)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89561 65c4cc65-6c06-0410-ace0-fbb531ad65f3
so we can handle multiple formats properly. This is not carved in stone,
but a proposal to start with.
We need to add support for transliterations as well as UTF8 handling,
propably with libiconv. Murf is looking into that for the dialplan.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89531 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In this commit:
- move the ast_register/unregister_app functions to module.h
to avoid the need to include pbx.h for the simpler apps;
- move the ast_group structure to channel.h to remove the
dependency of app.h on linkedlists.h
Note, this is a long process that I am doing in small steps.
The main difficulty is that now for each subsystem we
have a single header (e.g. channel.h) included by the subsystem
provider (usually one file, e.g. channel.c) and by its clients
(dozens of them, e.g. we have some 70+ apps and 30+ functions).
This requires the clients to include all the extra headers
required by the provider (eg. lock.h, linkedlists.h, definitions
of substructures...) even though many of the clients would be
just happy with opaque struct declarations and function prototypes.
The long term plan is to eventually rectify this structure
so that the compilation can become faster, and also APIs
are more stable.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89522 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to compat.h so it is always available - hopefully this will let
us reduce the number of inclusions of channel.h and frame.h
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89426 65c4cc65-6c06-0410-ace0-fbb531ad65f3
include/asterisk/autoconfig.h. Also, move the conditional include of sys/poll.h
or asterisk/poll-compat.h into asterisk/config.h instead of the two headers it
existed in before.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89361 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and the like (this could be used for gtk and gtk2 as well)
Other files: add tests for sdl, sdl_image and avcodec and regenerate
configure and autoconfig.h.in
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89351 65c4cc65-6c06-0410-ace0-fbb531ad65f3
comments on the content of these two files.
utils.h (which is included in over 150 files) contains a lot of
unrelated functions which require the inclusion of a large number
of other headers. At some point we should partition its content
in a better way.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89341 65c4cc65-6c06-0410-ace0-fbb531ad65f3
build times - tested, there is no measureable difference before and
after this commit.
In this change:
use asterisk/compat.h to include a small set of system headers:
inttypes.h, unistd.h, stddef.h, stddint.h, sys/types.h, stdarg.h,
stdlib.h, alloca.h, stdio.h
Where available, the inclusion is conditional on HAVE_FOO_H as determined
by autoconf.
Normally, source files should not include any of the above system headers,
and instead use either "asterisk.h" or "asterisk/compat.h" which does it
better.
For the time being I have left alone second-level directories
(main/db1-ast, etc.).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89325 | kpfleming | 2007-11-16 10:47:46 -0600 (Fri, 16 Nov 2007) | 4 lines
To help combat problems where people build external modules (asterisk-addons or others) and then change the build options of the Asterisk build in a way that makes the incompatible without warning, this commit introduces an MD5 signature of the important build-time options and includes that signature into modules when they are built. When the loader loads one of these modules and notices the problem, it will emit a warning to console and refuse to initialize the module, as doing so could cause the system to be unstable or even crash.
If you upgrade to this version of Asterisk, you must rebuild *all* of your modules that came from other sources before trying to run this version. If you are using Digium's G.729 binary codec module, you will need v33 or newer.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89326 65c4cc65-6c06-0410-ace0-fbb531ad65f3
through ast_mutex primitives.
To detect all occurrences, I have renamed the lock field in struct ast_channel
so it is clear that it shouldn't be used directly.
There are some uses in res/res_features.c (see details of the diff)
that are error prone as they try and lock two channels without
caring about the order (or without explaining why it is safe).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89293 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents modifying the strings in the stored variables,
and catched a few instances where this was actually done.
Given the differences between trunk and 1.4 (and the fact that this
is effectively an API change) it is better to fix 1.4 independently.
These are
chan_sip.c::sip_register()
chan_skinny.c:: near line 2847
config.c:: near line 1774
logger.c::make_components()
res_adsi.c:: near line 1049
I may have missed some instances for modules that do not build here.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- handle memory allocation failures
- add an ast_ prefix to a publicly exported function
- put curly braces in the right places
- add a bunch of spaces where they should be be used
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also fix a common typo I kept seeing (arguement) in various files.
Closes issue #11222, patch by snuffy (with arguement > argument by me).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89202 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- the *_CURRENT macros no longer need the list head pointer argument
- add AST_LIST_MOVE_CURRENT to encapsulate the remove/add operation when moving entries between lists
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89106 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Remove the AST_FORMAT_MAX_* types, as these are consuming 3 out of our available 32 bits.
- Add a native slin16 type, so that 16kHz codecs can translate without losing resolution.
(This doesn't affect anything immediately, until another codec has wb support.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89071 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r88805 | russell | 2007-11-05 16:07:54 -0600 (Mon, 05 Nov 2007) | 12 lines
After seeing crashes related to channel variables, I went looking around at the
ways that channel variables are handled. In general, they were not handled in
a thread-safe way. The channel _must_ be locked when reading or writing from/to
the channel variable list.
What I have done to improve this situation is to make pbx_builtin_setvar_helper()
and friends lock the channel when doing their thing. Asterisk API calls almost
all lock the channel for you as necessary, but this family of functions did not.
(closes issue #10923, reported by atis)
(closes issue #11159, reported by 850t)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88934 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r88931 | russell | 2007-11-06 07:50:15 -0600 (Tue, 06 Nov 2007) | 8 lines
Remove some checks to see if locks are initialized from the non-DEBUG_THREADS
versions of the lock routines. These are incorrect for a number of reasons:
- It breaks the build on mac.
- If there is a problem with locks not getting initialized, then the proper
fix is to find that place and fix the code so that it does get initialized.
- If additional debug code is needed to help find the problem areas, then this
type of things should _only_ be put in the DEBUG_THREADS wrappers.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r88719 | russell | 2007-11-05 14:40:01 -0600 (Mon, 05 Nov 2007) | 7 lines
Merge changes from asterisk/team/kpfleming/SRV-priority-handling
Previously, the SRV record support in Asterisk was broken. There was no
guarantee on what record Asterisk would choose to actually use. This set of
changes improves the situation by ensuring that Asterisk will choose the
highest priority record.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
details and examples are in include/asterisk/stringfields.h.
Not applicable to older branches except for 1.4 which will
receive a fix for the routines that free memory pools.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88454 65c4cc65-6c06-0410-ace0-fbb531ad65f3
