Age | Commit message (Collapse) | Author | Files | Lines |
|
(closes issue #12300)
Reported by: festr
Patches:
acl.c.patch uploaded by festr (license 443)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@111442 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
asterisk-users, where a user was using Playback, but needed the
features of Background, and had no idea that Background existed,
or that it might provide the features he needed. I thought the
best way to avert these kinds of queries was to provide "See Also"
references in all three of "Background", "Playback", "WaitExten".
Perhaps a project to do this with all related apps is in order.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@111391 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@111280 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(small "pops")
after (about 200ms later) an "incorrectly" sized frame was received.
While it would be very nice to keep this as optimized as possible, it makes no sense
for the smoother to be dropping random bits of audio like this. Isn't that the
whole point of a smoother?
Closes issue #12093.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@111245 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
thread.
This really should not make a difference except in very rare cases. That case would
be that all of the channels in autoservice are not generating any frames. In that
case, this change reduces the potential amount of time that a thread waits in
ast_autoservice_stop() for the autoservice thread to wrap back around to the beginning
of its loop.
(closes issue #12266, reported by dimas)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@110395 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
timestamps to be calculated as if they are audio frames.
(closes issue #11429)
Reported by: sperreault
Patches:
11429-frametype.diff uploaded by qwell (license 4)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@110019 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: tzafrir
Patches:
11442.patch uploaded by murf (license 17)
Tested by: murf
I didn't give tzafrir very much time to test this, but if he does
still have remaining issues, he is welcome to
re-open this bug, and we'll do what is called for.
I reproduced the problem, and tested the fix, so I hope I
am not jumping by just going ahead and committing the fix.
The problem was with what file_save does with templates;
firstly, it tended to print out multiple options:
[my_category](!)(templateref)
instead of
[my_category](!,templateref)
which is fixed by this patch.
Nextly, the code to suppress output of duplicate declarations
that would occur because the reader copies inherited declarations
down the hierarchy, was not working. Thus:
[master-template](!)
mastervar = bar
[template](!,master-template)
tvar = value
[cat](template)
catvar = val
would be rewritten as:
;!
;! Automatically generated configuration file
;! Filename: experiment.conf (/etc/asterisk/experiment.conf)
;! Generator: Manager
;! Creation Date: Tue Mar 18 23:17:46 2008
;!
[master-template](!)
mastervar = bar
[template](!,master-template)
mastervar = bar
tvar = value
[cat](template)
mastervar = bar
tvar = value
catvar = val
This has been fixed. Since the config reader 'explodes' inherited
vars into the category, users may, in certain circumstances, see
output different from what they originally entered, but it should
be both correct and equivalent.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@109908 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@109838 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
given payload does not exceed our maximum value.
(AST-2008-002)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@109386 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
via the "core show locks" command. The idea behind this section of code was
to remove the previous lock from the list if it was a trylock that had failed.
Unfortunately, instead of checking the status of the previous lock, we were referencing
the index immediately following the previous lock in the lock_info->locks array.
The result of this problem, under the right circumstances, was that the lock which
we currently in the process of attempting to acquire could "overwrite" the previous lock
which was acquired. While this does not in any way affect typical operation, it *could*
lead to misleading "core show locks" output.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@109226 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
1.4 as well.
Closes issue #12222.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@109057 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12228)
Reported by: andrew
Patches:
SRC.patch uploaded by andrew (license 240)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@108961 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
on the issue with mmichelson)
- Update copyright info on app_chanspy.
- Fix a race condition that caused app_chanspy to crash. The issue was that
the chanspy datastore magic that was used to ensure that spyee channels did
not disappear out from under the code did not completely solve the problem.
It was actually possible for chanspy to acquire a channel reference out of
its datastore to a channel that was in the middle of being destroyed. That
was because datastore destruction in ast_channel_free() was done near the
end. So, this left the code in app_chanspy accessing a channel that was
partially, or completely invalid because it was in the process of being free'd
by another thread. The following sort of shows the code path where the race
occurred:
=============================================================================
Thread 1 (PBX thread for spyee chan) || Thread 2 (chanspy)
--------------------------------------||-------------------------------------
ast_channel_free() ||
- remove channel from channel list ||
- lock/unlock the channel to ensure ||
that no references retrieved from ||
the channel list exist. ||
--------------------------------------||-------------------------------------
|| channel_spy()
- destroy some channel data || - Lock chanspy datastore
|| - Retrieve reference to channel
|| - lock channel
|| - Unlock chanspy datastore
--------------------------------------||-------------------------------------
- destroy channel datastores ||
- call chanspy datastore d'tor ||
which NULL's out the ds' || - Operate on the channel ...
reference to the channel ||
||
- free the channel ||
||
|| - unlock the channel
--------------------------------------||-------------------------------------
=============================================================================
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@108135 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
(inspired by issue #12187)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@108031 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
with Debian's gcc 4.3, 4.1 and 3.4)
(closes issue #12179)
Reported by: Netview
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@107408 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
- the output of flex includes a static function called 'input' that is not used, so for the moment we'll stop having the compiler tell us about unused variables in the flex source files (a better fix would be to improve our flex post-processing to remove the unused function)
- main/stdtime/localtime.c makes assumptions about signed integer overflow, and gcc-4.3's improved optimizer tries to take advantage of handling potential overflow conditions at compile time; for now, suppress these optimizations until we can fiure out if the code needs improvement
- main/udptl.c has some references to uninitialized variables; in one case there was no bug, but in the other it was certainly possibly for unexpected behavior to occur
- main/editline/readline.c had an unused variable
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@107352 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@107230 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
PBX is started on the channel using ast_pbx_start(), then the ownership of the
channel has been passed on to another thread. We can no longer access it in this
code. If the channel gets hung up very quickly, it is possible that we could
access a channel that has been free'd.
(inspired by BE-386)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@107161 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
on the channel (such as if you set a call limit based on the system's load
average), then there were cases where a channel that has already been free'd
using ast_hangup() got accessed. This caused weird memory corruption and
crashes to occur.
(fixes issue BE-386)
(much debugging credit goes to twilson, final patch written by me)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@107158 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@107102 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12175, reported by edantie, patched by me)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@107099 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
(closes issue #12124)
Reported by: dmartin
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@106842 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12168)
Reported by: plack
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@106788 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Closes issue #12154)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@106606 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #11958)
Reported by: norman
Patches:
20080209__bug11958.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@106552 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
ast_pbx_outgoing_app is called. The reason is that __ast_request_and_dial
allocates the cdr for the channel, so it should be expected that the channel
will have a cdr on it.
Thanks to joetester on IRC for pointing this out
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@106437 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
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
|
|
sure it is a different source.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105676 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
cleanup. Properly break out of the loop when a context isn't found when
verify that includes are valid.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105591 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
now is stuff that I have written recently ...
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105565 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@105563 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
so expand logic that clears emulation to AST_FRAME_NULL.
(closes issue #11911)
Reported by: edgreenberg
Patches:
v1-11911.patch uploaded by dimas (license 88)
Tested by: tbsky
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105560 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the list of channels in autoservice. The problem was that it was possible for
a channel to get removed from autoservice and destroyed, while the autoservice
thread was still messing with the channel. This led to memory corruption, and
caused crashes. This explains multiple backtraces I have seen that have
references to autoservice, but do to the nature of the issue (memory corruption),
could cause crashes in a number of areas.
(fixes the crash in BE-386)
(closes issue #11694)
(closes issue #11940)
The following issues could be related. If you are the reporter of one of these,
please update to include this fix and try again.
(potentially fixes issue #11189)
(potentially fixes issue #12107)
(potentially fixes issue #11573)
(potentially fixes issue #12008)
(potentially fixes issue #11189)
(potentially fixes issue #11993)
(potentially fixes issue #11791)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105409 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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
|
|
This protects against possible segfaults in applications that may try
to use data before checking length (ast_strdupa'ing it, for example)
(closes issue #12100)
Reported by: foxfire
Patches:
12100-nullappargs.diff uploaded by qwell (license 4)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105005 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12081)
Reported by: jcollie
Patches:
asterisk-1.4.18-funcdesc.patch uploaded by jcollie (license 412)
Tested by: jcollie, Corydon76
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104868 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
1. Make the list of ast_dial_channels a lockable list. This is because in some cases,
the ast_dial may exist in multiple threads due to asynchronous execution of its application, and
I found some cases where race conditions could exist.
2. Check in ast_dial_join to be sure that the channel still exists before attempting to lock it, since
it could have gotten hung up but the is_running_app flag on the ast_dial_channel may not have been
cleared yet.
(closes issue #12038)
Reported by: jvandal
Patches:
12038v2.patch uploaded by putnopvut (license 60)
Tested by: jvandal
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104841 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
like crazy on every fileexists_core call.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104783 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104704 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104665 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
list to protect the contents instead of the overall module list lock.
(closes issue #12080)
Reported by: ChaseVenters
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104596 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
directory layout
(closes issue #11831)
Reported by: IgorG
Patches:
fallbacken.v1.diff uploaded by IgorG (license 20) (modified by me to improve code and conform rest of function to coding guidelines)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104593 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
failed to lock don't sit around in the history. When a lock is first locked,
this checks to see if the last lock in the list was one that was failed to be
locked. If it is, then that was a lock that we're no longer sitting in a trylock
loop trying to lock, so just remove it.
(inspired by issue #11712)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104102 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
depth was only 1.
Specifically, this fixes using #include and #exec in extconfig.conf.
This was basically caused because the config file itself raises the include level to 1.
I opted not to raise the include limit, because recursion here could cause very bizarre behavior.
Pointed out, and tested by jmls
(closes issue #12064)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104092 f38db490-d61c-443f-a65b-d21fe96a405b
|