| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Reported by: tomaso
Patches:
asterisk-1.6.0-rc2-cdrmemleak.patch uploaded by tomaso (license 564)
I basically spent the day, verifying that this patch
solves the problem, and doesn't hurt in non-problem
cases. Why valgrind did not plainly reveal this leak
absolutely mystifies and stuns me.
Many, many thanks to tomaso for finding and providing the fix.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140670 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
make sense.
(Closes issue #13124)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@135949 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The purpose of this branch was to take into account
"burps" which could cause jitterbuffers to misbehave.
One such example is if the L option to Dial() were used
to inject audio into a bridged conversation at regular
intervals. Since the audio here was not passed through
the jitterbuffer, it would cause a gap in the jitterbuffer's
timestamps which would cause a frames to be dropped for a
brief period.
Now ast_generic_bridge will empty and reset the jitterbuffer
each time it is called. This causes injected audio to be handled
properly.
ast_generic_bridge also will empty and reset the jitterbuffer
if it receives an AST_CONTROL_SRCUPDATE frame since the change
in audio source could negatively affect the jitterbuffer.
All of this was made possible by adding a new public API call
to the abstract_jb called ast_jb_empty_and_reset.
(closes issue #11259)
Reported by: plack
Tested by: putnopvut
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@135841 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: bcnit
Tested by: murf
I discovered that also, in the previous bug fixes and changes,
the cdr.conf 'unanswered' option is not being obeyed, so
I fixed this.
And, yes, there are two 'answer' times involved in this
scenario, and I would agree with you, that the first
answer time is the time that should appear in the CDR.
(the second 'answer' time is the time that the bridge
was begun).
I made the necessary adjustments, recording the first
answer time into the peer cdr, and then using that to
override the bridge cdr's value.
To get the 'unanswered' CDRs to appear, I purposely
output them, using the dial cmd to mark them as
DIALED (with a new flag), and outputting them if
they bear that flag, and you are in the right mode.
I also corrected one small mention of the Zap device
to equally consider the dahdi device.
I heavily tested 10-sec-wait macros in dial, and
without the macro call; I tested hangups while the
macro was running vs. letting the macro complete
and the bridge form. Looks OK. Removed all the
instrumentation and debug.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@135799 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
terms of the device argument (only without the unique identifier appended).
(closes issue #12771)
Reported by: davidw
Patches:
20080717__bug12771.diff.txt uploaded by Corydon76 (license 14)
Tested by: davidw, jvandal, murf
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@133649 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
this tree is not yet ready for users to be easily upgrading or switching, but it needs to be :-)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@130298 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #10927)
Reported by: murf
Tested by: murf, deeperror
(closes issue #12907)
Reported by: falves11
Tested by: murf, falves11
(closes issue #11849)
Reported by: greyvoip
As to 11849, I think these changes fix the core problems
brought up in that bug, but perhaps not the more global
problems created by the limitations of CDR's themselves
not being oriented around transfers.
Reopen if necc, but bug reports are not the best
medium for enhancement discussions. We need to start
a second-generation CDR standardization effort to cover
transfers.
(closes issue #11093)
Reported by: rossbeer
Tested by: greyvoip, murf
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@127663 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
are possible.
(Closes issue #12848)
Reported by klaus3000
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@123930 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
should continue working. Release announcement to follow.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@122314 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
that situation before it causes a deadlock. (Reported and tested by ctooley
via #asterisk-dev)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@122130 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
printed is not nonsensical (reported by mvanbaak via #asterisk-bugs).
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@121861 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
broke out of a native bridge and fell through to generic.
(closes issue #12815)
Reported by: ramonpeek
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@121442 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
less than the defined minimum digit length, and the other end only wants END
digits (SIP INFO, for example).
(closes issue #12778)
Reported by: tsearle
Patches:
12778.rev1.txt uploaded by russell (license 2)
Tested by: tsearle
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@121280 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
in if dev-mode is enabled, and only aborts if DO_CRASH is defined.
(inspired by issue #12650)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@116463 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
defined.
After debugging a deadlock, it was noticed that when DEBUG_CHANNEL_LOCKS
is enabled in menuselect, the actual origin of channel locks is obscured
by the fact that all channel locks appear to happen in the function
ast_channel_lock(). This code change redefines ast_channel_lock to be a
macro which maps to __ast_channel_lock(), which then relays the proper
file name, line number, and function name information to the core lock
functions so that this information will be displayed in the case that
there is some sort of locking error or core show locks is issued.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@116088 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
I ran into some problems with G.722 in 1.4, so I have merged in all of the fixes
in this area that I have made in trunk/1.6.0, and things are happy again.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114550 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
cleared an issue someone was seeing when attempting to show channels when
the load was high.
(closes issue #11667)
Reported by: falves11
Patches:
11677.txt uploaded by russell (license 2)
Tested by: falves11
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114117 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
case the generate callback goes NULL on us after the channel is unlocked. Thanks
to Russell for pointing this need out to me.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114106 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
deadlock prevention in place in chan_local, but it would not work in a specific
case because the channel was recursively locked. By unlocking the channel prior
to calling the generator's generate callback in ast_read_generator_actions(), we
prevent the recursive locking, and therefore the deadlock.
(closes issue #12307)
Reported by: callguy
Patches:
12307.patch uploaded by putnopvut (license 60)
Tested by: callguy
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@113065 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
|
|
(inspired by issue #12187)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@108031 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
|
|
(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 #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
|
|
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
|
|
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
|
|
(closes issue #11740)
Reported by: gserra
Patches:
v1-11740.patch uploaded by dimas (license 88)
(closes issue #11955)
Reported by: tsearle
(closes issue #10530)
Reported by: xmarksthespot
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@103801 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
internally at Digium by Steve Pitts.
- Fix up chan_local to ensure that the channel lock is held before the local
pvt lock.
- Don't hold the channel lock when executing the timing function, as it can
cause a deadlock when using chan_local. This actually changes the code back
to be how it was before the change for issue #10765. But, I added some other
locking that I think will prevent the problem reported there, as well.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@100581 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
take care of current known spy issues.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@98972 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #10574, reported by boch, patched by moy)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@98315 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Just return 0.
(closes issue #11540)
Reported by: tzafrir
Patches:
group_empty.diff uploaded by tzafrir (license 46)
-- slightly changed by me
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@95024 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
inserted into the channel list. The reason is because some manager users
immediately queue requests from the channel when they see that event and are
confused when Asterisk reports no such channel. (Closes issue #11632)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@94767 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
channels which were being monitored
had one audio file recorded and one empty audio file saved.
(closes issue #11529, reported by atis patched by me)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@93625 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
sure to close it.
Issue 11454, patch by eliel.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90876 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@90735 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
operation happens. (issue #BE-88)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90548 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@90145 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
free the scheduler context.
(closes issue #11355)
Reported by: eliel
Patches:
main.channel.c.patch uploaded by eliel (license 64)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89577 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: atis
Patch by: tilghman
Fixes issue #10923
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89184 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
callback agents.
(closes issue #11071, reported by callguy, patched by me, tested by callguy and Ted Brown)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@88826 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The issue here is that the channel frame readq handling got broken when the
code was converted to use the linked list macros. It caused corruption of the
list head and tail pointers. So, I fixed up the usage of the linked list
macros and in passing, simplified the code. I also documented what the code
is doing, as it was a bit difficult to figure out at first.
This bug showed itself with crashes showing messed up head/tail pointers for
the readq. However, there are a couple of crashes that aren't quite as obvious,
but I think may be related. So, if your bug gets closed by this commit, but
you still have a problem, please reopen or create a new bug report.
(closes issue #10936)
(closes issue #10595)
(closes issue #10368)
(closes issue #11084)
(closes issue #10040)
(closes issue #10840)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@88709 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
any channel datastores from the old channel to the new one. However, it did
not use the linked list macros properly to accomplish the task. The existing
code would only work if there was only a single datastore on the old channel.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@88624 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
and ast_string_field_free_all to ast_string_field_reset_all
to avoid misuse (due to too similar names and an error in
documentation). Fix two related memory leaks in app_meetme.
No need to merge to trunk, different fix already applied there.
Not applicable to 1.2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@88471 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
require the user to do that
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@87069 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the BEGIN is less than that of the defined minimum DTMF duration.
(closes issue #11051)
Reported by: casper
Patches:
channel.c.86664.diff uploaded by casper (license 55)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@86750 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #11050)
Reported by: slavon
Patches:
channel.c.86662.diff uploaded by casper (license 55)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@86663 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
and modify channel data that may change elsewhere. I went through every timer
callback in the source tree to make sure that none of them did any additional
locking that could introduce deadlocks, and all is well.
(closes issue #10765)
Reported by: Ivan
Patches:
ast_1_4_11_svn_patch_channel_rc.diff uploaded by Ivan (license 229)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@86330 f38db490-d61c-443f-a65b-d21fe96a405b
|
